Re: [Xen-devel] [PATCH v5 4/9] xen: introduce XEN_DOMCTL_devour

[Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>]

"Jan Beulich" <JBeulich@xxxxxxxx> writes:

>>>> On 13.01.15 at 17:17, <vkuznets@xxxxxxxxxx> wrote:
>> Ian Campbell <Ian.Campbell@xxxxxxxxxx> writes:
>>> An alternative approach to this might be to walk the guest p2m (with
>>> appropriate continuations) and move each domheap page (this would also
>>> help us preserve super page mappings). It would also have the advantage
>>> of not needing additional stages in the destroy path and state in struct
>>> domain etc, since all the action would be constrained to the one
>>> hypercall.
>> 
>> Something like that (but not exactly) was in my RFC/WIPv2 series:
>> http://lists.xen.org/archives/html/xen-devel/2014-09/msg03624.html 
>> 
>> The drawback of such approach is the necessity of copying all mapped
>> more than once pages (granted pages, qemu-mapped pages, ...) or at least
>> providing blank pages instead of them. 
>
> Why would that be necessary only in that alternative model? What
> gets done with pages used by other than _just_ the dying domain
> shouldn't depend on how the MFN/GFN relationship gets determined.

The difference comes from the fact that in the current model (when we
have a hook in free_domheap_pages()) we don't care who frees the
particular page first - our dying domain or e.g. a backend from dom0,
eventually all pages are freed. In the alternative model (one hypercall
reassigning all pages) we need to go through all domheap pages before
we start domain cleanup (unless we modify the domain cleanup path) or
some or all pages may got lost.

-- 
  Vitaly

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel