From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] evtchn: make EVTCHNOP_reset suitable for kexec Date: Fri, 25 Jul 2014 18:06:12 +0100 Message-ID: <53D28E84.4010802@citrix.com> References: <1406303329-21724-1-git-send-email-vkuznets@redhat.com> <53D27EA1.9030906@citrix.com> <87bnsdjthm.fsf@vitty.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XAiwn-0004YV-Ka for xen-devel@lists.xenproject.org; Fri, 25 Jul 2014 17:06:21 +0000 In-Reply-To: <87bnsdjthm.fsf@vitty.brq.redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Vitaly Kuznetsov Cc: Andrew Jones , Ian Campbell , Ian Jackson , Tim Deegan , David Vrabel , Jan Beulich , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On 25/07/14 17:25, Vitaly Kuznetsov wrote: > Andrew Cooper 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 >> 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