xen-devel
Re: [Xen-devel] [PATCH] iomem: Prevent Dom0 pci bus from allocating RAM
To: |
"Li, Xin" <xin.li@xxxxxxxxx> |
Subject: |
Re: [Xen-devel] [PATCH] iomem: Prevent Dom0 pci bus from allocating RAM as I/O space in 2.6.32.27 tree. |
From: |
Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> |
Date: |
Thu, 17 Feb 2011 10:35:48 -0500 |
Cc: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, "Zhang, Fengzhe" <fengzhe.zhang@xxxxxxxxx> |
Delivery-date: |
Thu, 17 Feb 2011 07:37:55 -0800 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<FC2FB65B4D919844ADE4BE3C2BB739AD36A78D7D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<1A42CE6F5F474C41B63392A5F80372B2335E978C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20110216150638.GC12215@xxxxxxxxxxxx> <20110216152021.GA5894@xxxxxxxxxxxx> <20110216154759.GA3921@xxxxxxxxxxxx> <4D5CB2DF.80604@xxxxxxxxx> <20110217142338.GC5987@xxxxxxxxxxxx> <FC2FB65B4D919844ADE4BE3C2BB739AD36A78D7D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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
|
|
|