From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH RFCv2 1/1] Introduce VCPUOP_reset_vcpu_info Date: Fri, 15 Aug 2014 16:07:06 +0100 Message-ID: <53EE302A02000078000BA8DF@mail.emea.novell.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><53ED538302000078000BA822@mail.emea.novell.com> (Jan Beulich's message of "Fri, 15 Aug 2014 00:25:39 +0100") <8761hu13hf.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.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XIJ5y-00033M-2a for xen-devel@lists.xenproject.org; Fri, 15 Aug 2014 15:07:10 +0000 In-Reply-To: <8761hu13hf.fsf@vitty.brq.redhat.com> Content-Disposition: inline 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: xen-devel@lists.xenproject.org, Andrew Jones , David Vrabel , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org >>> On 15.08.14 at 11:55, wrote: > "Jan Beulich" writes: >>>>> On 14.08.14 at 10:28, wrote: >>> --- 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.. But you always ought to remember that when your changing hypervisor code or the public interface (including comments) that nothing here should b Linux-centric, i.e. you want to describe abstract behavior here, not how Linux might be making use of it. Jan