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] treatment grant frames during save/restore

>>> On 28.05.10 at 10:22, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
> On 28/05/2010 09:01, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> Wouldn't is suffice to adjust XEN_DOMCTL_getpageframeinfo{2,3} to
>> report these pages as special (not sure whether a new type would
>> be needed, or whether simply returning XEN_DOMCTL_PFINFO_XTAB
>> would be acceptable), thus allowing the tools to skip them as
>> necessary? This of course implies that the tools would need to issue
>> the call for HVM guests (currently I think they do so only for PV ones),
>> that the actual page contents is irrelevant post-restore, and that
>> there being a hole in the physical address space post-restore isn't
>> a problem for the pv drivers.
> Yep that would probably work. And also potentially gets rid of one lot of
> "if-hvm-else-pv" branched code in xc_domain_save.c. I'd take a patch to do
> that if you want to pick this item up.

I'm afraid it won't: The live_p2m table gets created for pv guests only,
but is needed as a prerequisite to calling XEN_DOMCTL_getpageframeinfo*
(which wants MFNs as input). Hence while the hypervisor side patch is
trivial, it doesn't get us any closer to a solution to the problem at hand.

Unless we (re-)define the meaning of the input array to this domctl to
specify gmfn-s rather than mfn-s (at least for the hvm case; for
auto-translate pv guests, quite obviously the save code wouldn't
work anyway, but for those passing in gmfn-s would seem the
natural thing here).

Or unless we want to add code to libxc to create a live_p2m for all
guests (which I wouldn't want to take on).


Xen-devel mailing list