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: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Tue, 16 Nov 2010 10:01:33 -0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, "bruce.edge@xxxxxxxxx" <bruce.edge@xxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
Delivery-date: Tue, 16 Nov 2010 10:02:58 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C9080945.A1AE%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>
References: <C9080945.A1AE%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101027 Fedora/3.1.6-1.fc13 Lightning/1.0b3pre Thunderbird/3.1.6
On 11/16/2010 02:11 AM, Keir Fraser wrote:
> On 16/11/2010 10:02, "Ian Campbell" <Ian.Campbell@xxxxxxxxxxxxx> wrote:
>>> The right answer is probably to refuse save/restore/migrate when devices are
>>> passed through.
>> Absolutely. 
>> 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?).
> Leave the hole empty and populate on demand when devices are passed through
> would seem sensible.

Actually I was originally thinking that the hole would all be
INVALID_MFN but then pfn_to_mfn() would translate that to being an
identity translation.  But that's pretty hacky, and only works if you
actually want identity.  On-demand population of regions is much cleaner.


Xen-devel mailing list

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