This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [RFC Patch] Support for making an E820 PCI hole in tools

To: Keir Fraser <keir@xxxxxxx>
Subject: Re: [Xen-devel] [RFC Patch] Support for making an E820 PCI hole in toolstack (xl + xm)
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Tue, 16 Nov 2010 10:02:44 +0000
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>, "bruce.edge@xxxxxxxxx" <bruce.edge@xxxxxxxxx>, Stefano, Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
Delivery-date: Tue, 16 Nov 2010 02:03:46 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C90804E9.A1A3%keir@xxxxxxx>
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>
Organization: Citrix Systems, Inc.
References: <C90804E9.A1A3%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2010-11-16 at 09:52 +0000, Keir Fraser wrote:
> On 16/11/2010 09:26, "Ian Campbell" <Ian.Campbell@xxxxxxxxxx> wrote:
> >>> We do make the PTE that refer to physical devices to be the DOM_IO
> >> domain..
> >> 
> >> I think Xen will sort that out for itself when presented with a
> >> hardware/device mfn.
> > 
> > My main concern would be with save/restore code will canonicalise all
> > the MFNs in the page tables back into PFNs and then convert back to MFNs
> > on the other side, which is likely to go pretty wrong on one end of the
> > other unless the save restore code is aware of which MFNs are device
> > MFNs and which are actual memory. I'm not sure there is any way it can
> > tell.
> The right answer is probably to refuse save/restore/migrate when devices are
> passed through.


However we are talking about setting up a 1-1 mapping in the P2M region
corresponding to the PCI hole at guest boot and preserving that until
such a time as a device is plugged in, which may be after a migration. 

I don't think it matters that no device is passed through at the time of
the migration, in this configuration we still need arrange for the
relevant P2M entries to be correct after the migration (or at least
before the device gets plugged in, perhaps we can leave holes and only
establish the 1-1 p2m on demand in pcifront?).

So long as this configuration doesn't cause the save/restore code to go
mad it's something we can likely fixup in the guest on restore. My worry
is that the save/restore code will just barf before we get that


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>