Re: [Xen-devel] [RFC Patch] Support for making an E820 PCI hole in toolstack (xl + xm)

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

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.

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

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

Ian.



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