[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.