Re: [PATCH v7 00/10] toolstack-based approach to pvhvm guest kexec

[Vitaly Kuznetsov <vkuznets@redhat.com>]

"Jan Beulich" <JBeulich@suse.com> writes:

>>>> On 28.05.15 at 14:27, <vkuznets@redhat.com> wrote:
>> "Jan Beulich" <JBeulich@suse.com> writes:
>> 
>>>>>> On 27.05.15 at 17:25, <vkuznets@redhat.com> wrote:
>>>> This patch series provides x86 PVHVM domains with an ability to perform
>>>> kexec/kdump-style operations.
>>>
>>> Before I get to look at this latest version, may I go a step back and
>>> ask for clarification whether all of these (seemingly fragile)
>>> manipulations are actually needed (such a rationale for the series
>>> would btw be quite good to have in the overview mail, rather than
>>> having to wade through mailing list history). In particular, why is it
>>> that we need a new domain in the first place? After all, native
>>> kexec doesn't imply a new physical machine either. Perhaps that
>>> was discussed a long while back, but I can't seem to find any of
>>> that now that I would like to read through it again.
>> 
>> Yes, here are some highlights from last year's discussion:
>> 
>> http://lists.xen.org/archives/html/xen-devel/2014-08/msg01908.html 
>> 
>> http://lists.xen.org/archives/html/xen-devel/2014-08/msg01979.html 
>
> I.e. what you currently implement is David's model without Konrad's
> later alternative really having been explored? Iiuc David's main
> reservation (which I share) was against a myriad of reset-this and
> reset-that hypercalls, which Konrad's reset-everything would
> address equally well.

I was under an impression Konrad was also suggesting building a new
domain with "instead of chasing down different states (event channels,
grants, vcpu's, pagetables, etc) we would wipe everything to a nice
clean slate" (as we'll have to chase down all this bits with a
'reset-everything' hypercall) but now I'm not sure.

AFAICT If we follow down the 'reset-everything' road it's not going to
be any easier and less fragile. E.g. I don't see an easy way to deal
with grants: even if we can clean all the internal bits we still have
pages mapped to the backend domain (Qemu and other backends) and there
is no easy way to ask them to unmap everything. We could (in theory)
walk through all the pages of our domain replacing all pages which need
replacement with empty pages but we need to temporary assign old pages
somewhere, avoid over-allocation (as e.g. in tot_pages = max_pages case
we can't add a single page to the domain). The support burden of a
'reset-everything' hypercall is also going to be heavier as all newly
added bits will have to be added to it.

The approach used in this series is not significantly different from how
an HVM domain is doing normal reboot: we destroy the original domain and
create a new one instead of cleaning up the original one (as it looks
safer and much easier I suppose).

-- 
  Vitaly