Mailing List Archive

http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1726





------- Comment #5 from konrad.wilk@oracle.com 2011-01-31 11:11 -------
> Fengzhe already find the root cause.
^^^^- found?


What is the root cause? Or is he trying to narrow down the root cause?


--
Configure bugmail: http://bugzilla.xensource.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

_______________________________________________
Xen-bugs mailing list
Xen-bugs@lists.xensource.com
http://lists.xensource.com/xen-bugs

http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1726





------- Comment #6 from shaohui.zheng@intel.com 2011-01-31 18:36 -------
Copied from Fengzhe's email.

In intel_i9xx_setup_flush (intel-agp.c), agp driver tries to map a "Flush Page"
using ioremap_nocache(). But the I/O page address passed to ioremap_nocache()
is not valid in both P2M and M2P tables. The page address is always 8MB over
max dom0_mem.

If I remove the ioremap logic, dom0 can boot successfully with no noticeable
error. The bug is reproduced on HP 7800p machine with Core2 processor and Q35
motherboard.


--
Configure bugmail: http://bugzilla.xensource.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

_______________________________________________
Xen-bugs mailing list
Xen-bugs@lists.xensource.com
http://lists.xensource.com/xen-bugs

http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1726





------- Comment #7 from konrad.wilk@oracle.com 2011-02-01 11:20 -------
(In reply to comment #6)
> Copied from Fengzhe's email.
>
> In intel_i9xx_setup_flush (intel-agp.c), agp driver tries to map a "Flush Page"
> using ioremap_nocache(). But the I/O page address passed to ioremap_nocache()
> is not valid in both P2M and M2P tables. The page address is always 8MB over
> max dom0_mem.

Right.. But the ioremap_nocache append the _PAGE_IOMAP flag, which ends up
going in xen_make_pte, which checks for this:

538 if (unlikely(pte & _PAGE_IOMAP) &&
539 (xen_initial_domain() || addr >= ISA_END_ADDRESS)) {
540 pte = iomap_pte(pte);

and calls iomap_pte which just uses the provided PFN and does not consult the
P2M.

In the 'xen_pte_val' (which is used right before setting the PTE), we also
check the _PAGE_IOMAP:
477 if (xen_initial_domain() && (pteval & _PAGE_IOMAP))
478 return pteval;

and don't consult the M2P.


So there is no consulting of the M2P or P2M if the _PAGE_IOMAP flag is
provided...

Could it be that some later somebody removes the _PAGE_IOMAP?

Or is the _PAGE_IOMAP somehow not set? (The ioremap_caller sets the prot to
PAGE_KERNEL_IO_UC_MINUS which has the _PAGE_IOMAP).


>
> If I remove the ioremap logic, dom0 can boot successfully with no noticeable
> error. The bug is reproduced on HP 7800p machine with Core2 processor and Q35
> motherboard.
>


--
Configure bugmail: http://bugzilla.xensource.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

_______________________________________________
Xen-bugs mailing list
Xen-bugs@lists.xensource.com
http://lists.xensource.com/xen-bugs