[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH] iomem: Prevent Dom0 pci bus from allocating RAM as I/O space in 2.6.32.27 tree.



> > However, I still doubt if the igb device is working correctly. The
> 
> OK, that is a different bug, if it is a bug.
> 
> > sequence that igb driver do ioremap is like this:
> >
> > 1. igb calls function pci_ubs_alloc_resource to get some non-RAM pages.
> > 2. igb sets the phys_addr of the pages in some BAR.
> > 3. igb ioremaps these pages.
> >
> > After patching, it looks like ioremap gets some mfn allocated by
> > Xen. But what set in BAR is still phys_addr. If igb device tries to
> 
> No. It just sets the PTE to the PFN.

Then it's just a workaround to the crash.  The PFN allocated in dom0 is 
actually Xen RAM page, thus the driver may corrupt the page which actually 
belongs to Xen or other domain.

> 
> > access the pages directly, would Xen be able to intercept and
> > translate it? And also, how the contiguity of mfns be guaranteed?
> 
> B/c we don't touch the P2M mapping. We bypass that altogether
> and set the PTE with the phys_addr (which is based on the BARs).
> We can do that since those PFN's belong to the DOMID_IO which
> has a different mechanism for checking the MFN continuity (it
> uses ranges). 

I'm still not persuaded this is a reasonable fix.  I'm still thinking Xen can't 
use the PFN from dom0, it's guest PFN allocated in dom0 according to its e820 
which falls into host RAM range.

Thanks!
-Xin

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.