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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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?