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 01:32:15PM +0800, Fengzhe Zhang wrote:
> On 2011/2/16 23:47, Konrad Rzeszutek Wilk wrote:
> >On Wed, Feb 16, 2011 at 10:20:21AM -0500, Konrad Rzeszutek Wilk wrote:
> >>On Wed, Feb 16, 2011 at 10:06:38AM -0500, Konrad Rzeszutek Wilk wrote:
> >>>On Wed, Feb 16, 2011 at 10:26:20PM +0800, Zhang, Fengzhe wrote:
> >>>>iomem: Prevent Dom0 pci bus from allocating RAM as I/O space
> >>>
> >>>Is there a bug # associated with this? Is this associated with the intel-agp
> >>>driver trying to ioremap the scratch page and bombing out?
> >
> >Also did you try to revert 0b56d9994ebe34df77fa156d2068ad93b7877b44 and see
> >how that works? Here is the revert attached
> >
> 
> I tried this patch and it can indeed avoid system crash.

Jeremy,

Could you revert 0b56d9994ebe34df77fa156d2068ad93b7877b44 please?

> 
> 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.

> 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).

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