Re: [Xen-devel] [PATCH] evtchn: make EVTCHNOP_reset suitable for kexec

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 25/07/14 17:25, Vitaly Kuznetsov wrote:
> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> writes:
>
>> On 25/07/14 16:48, Vitaly Kuznetsov wrote:
>>> It would be nice to allow guests to close all event channels in
>>> ABI-agnostic way on startup. This would allow a guest to perform
>>> full cleanup in case of kexec/kdump. EVTCHNOP_reset looks suitable
>>> for this purpose. However it has two issues:
>>>
>>> - current implementation unconditionally closes all event channels
>>>   including store/console channels mapped to Dom0. There is no way
>>>   for a guest to restore these channels after they were closed.
>>>
>>> - control blocks for vcpus need cleanup when FIFO ABI is being used.
>>>
>>> With this change a guest can simply do EVTCHNOP_reset before its
>>> init in both 2-level and FIFO cases. Unfortunately we'll need to
>>> put something like "xen_version >= 4.5" check before doing it as
>>> if we do it with the old implementation the guest will get stuck.
>>>
>>> The issue can also be solved by introducing a new EVTCHNOP
>>> operation but it seems that EVTCHNOP_reset was originally designed
>>> for such reset and it's not being used at this moment.
>>>
>>> [The idea was suggested by Ian Campbell and Andrew Cooper]
>>>
>>> Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
>> This patch is looking very much better than its predecessor.
>>
> Thanks!
>
>> The xenstore and console event channels are set up by the toolstack for
>> the domain, and not expected to be set up by the domain itself;  They
>> are fine to be exempt here.
>>
>> However, all other event channels to dom0 are not special in the
>> slightest, and should be reset.  They can be re-negotiated with the
>> backends via the usual xenstore methods.
> I agree. Unfortunately I wasn't able to figure out how to distinguish
> between store/console channels and all other interdomain channels bound
> to dom0 (I know toolstack has this information, but how would we check
> that in hypervisor?) Any suggestions are more than welcome!

Hmm - HVM guests are easy; the information is in the hvm params.

PV guests however are going to require some creative thinking.

The start_info page contains the required information, but Xen has
nothing to do with this page; it is just another guest page which
happens to have some magic values placed there by the toolstack.  In the
case of a domain kexec, there is no guarentee that the start_info page
still contains valid data, so even if Xen could map the page, its
content cant be relied upon.

I can't think of a reasonable way of doing this which doesn't involve
modifying the toolstack to explicitly provide that information for PV
guests.

~Andrew

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