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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Feb 17, 2011 at 11:07:35PM +0800, Li, Xin wrote:
> > > 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.

Are we taking about the crash that is fixed if you revert
0b56d9994ebe34df77fa156d2068ad93b7877b44?

Or is this about the igb - if so can you create a new thread with the
serial output for that crash.
> 
> > 
> > > 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.

Looking at the crash serial output, the Xen hypervisor thinks from looking at 
its M2P list
that this is a DOMID_IO page.... ? So it wouldn't be shared by other guests?

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