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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.05.15 at 14:27, <vkuznets@xxxxxxxxxx> wrote:
> "Jan Beulich" <JBeulich@xxxxxxxx> writes:
> 
>>>>> On 27.05.15 at 17:25, <vkuznets@xxxxxxxxxx> 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.

Jan


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