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

[Keir Fraser <keir@xxxxxxx>]

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. It's somewhere between very hard and very nuts to attempt
that in general. For example, even with SR-IOV, we've only been talking
about it so far for NICs, and then in terms of having a Solarflare-like
acceleration abstraction allowing us to step off of SR-IOV for at least the
duration of the critical bit of the save/restore.

A sensible first goal would simply be to be able to do PCI passthrough both
before and after a s/r/m across reasonaly heterogenous hardware, but not
attempt to be able to maintain such a device passthru *during* the s/r/m.

 -- Keir



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