From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vitaly Kuznetsov Subject: Re: [PATCH RFCv2 1/1] Introduce VCPUOP_reset_vcpu_info Date: Fri, 15 Aug 2014 11:55:40 +0200 Message-ID: <8761hu13hf.fsf@vitty.brq.redhat.com> References: <1408004882-7256-1-git-send-email-vkuznets@redhat.com> <1408004882-7256-2-git-send-email-vkuznets@redhat.com> <53ED538302000078000BA822@mail.emea.novell.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 1XIEEk-00077T-Ao for xen-devel@lists.xenproject.org; Fri, 15 Aug 2014 09:55:54 +0000 In-Reply-To: <53ED538302000078000BA822@mail.emea.novell.com> (Jan Beulich's message of "Fri, 15 Aug 2014 00:25:39 +0100") List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Andrew Jones , David Vrabel , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org "Jan Beulich" writes: >>>> On 14.08.14 at 10:28, wrote: >> Changes from RFCv1: >> - Don't use unsuitable unmap_vcpu_info(), rewrite [Jan Beulich] > > I don't think I said that - you now basically open code most what > is in that function. Instead I was rather hinting towards adding a > flag to the function to adjust the function's behavior to the then > two different purposes. > Sorry I misunderstood.. I'll rewrite and send as first non-RFC. >> --- a/xen/include/public/vcpu.h >> +++ b/xen/include/public/vcpu.h >> @@ -227,6 +227,20 @@ struct vcpu_register_time_memory_area { >> typedef struct vcpu_register_time_memory_area vcpu_register_time_memory_area_t; >> DEFINE_XEN_GUEST_HANDLE(vcpu_register_time_memory_area_t); >> >> +/* >> + * Reset all of the vcpu_info information from their previous location >> + * to the default one used at bootup. The following prerequisites should be met: >> + * 1. VCPU should be switched off. This means the operation is unsupported for >> + * boot VCPU. > > Boot vCPU? I don't think this should be written more restrictively > than it is. Just the one CPU doing the resets can't be resetting > itself. With some effort I think one could even get a reset for all > of them working. I thought about something simillar to what we have in map_vcpu_info: allow the operation for all offline VCPUs and the current one. But then I realized that boot VCPU doesn't perform VCPUOP_register_vcpu_info in current linux kernel so there is no need to unregister atm.. I'll play with it a bit more. > >> + * 2. Domain should not be using FIFO-based event channel ABI. In case it is in >> + * use domain is supposed to switch back to 2-level ABI with EVTCHNOP_reset. > > I'd prefer this to be worded more generically: Avoid mentioning > the FIFO ABI, and just require resetting _any_ (current or future) > non-default event channel ABI to be switched back to 2-level. Sure, thanks! > > Jan -- Vitaly