From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 01 Jul 2013 23:09:56 +0000 Subject: Re: RFC: proposal for VM reset & shutdown hcall Message-Id: <1372720196.8183.97@snotra> List-Id: References: <9F6FE96B71CF29479FF1CDC8046E1503632A49@039-SN1MPN1-004.039d.mgd.msft.net> <3B5BAAFB-161D-4D5E-8B01-401E0C8AD72D@suse.de> <9F6FE96B71CF29479FF1CDC8046E1503632A9B@039-SN1MPN1-004.039d.mgd.msft.net> <426615FE-3632-4735-84F4-3F7D5AF143F4@suse.de> <9F6FE96B71CF29479FF1CDC8046E1503632B01@039-SN1MPN1-004.039d.mgd.msft.net> In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E1503632B01@039-SN1MPN1-004.039d.mgd.msft.net> (from B08248@freescale.com on Mon Jul 1 18:05:55 2013) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Yoder Stuart-B08248 Cc: Alexander Graf , Bhushan Bharat-R65777 , Wood Scott-B07421 , "kvm@vger.kernel.org list" , "kvm-ppc@vger.kernel.org" On 07/01/2013 06:05:55 PM, Yoder Stuart-B08248 wrote: > > > > -----Original Message----- > > From: Alexander Graf [mailto:agraf@suse.de] > > Sent: Monday, July 01, 2013 6:01 PM > > To: Yoder Stuart-B08248 > > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org > list; kvm-ppc@vger.kernel.org > > Subject: Re: RFC: proposal for VM reset & shutdown hcall > > > > > > On 02.07.2013, at 00:59, Yoder Stuart-B08248 wrote: > > > > > > > > > > >> -----Original Message----- > > >> From: kvm-ppc-owner@vger.kernel.org > [mailto:kvm-ppc-owner@vger.kernel.org] On Behalf Of Alexander > > Graf > > >> Sent: Monday, July 01, 2013 5:14 PM > > >> To: Yoder Stuart-B08248 > > >> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; > kvm@vger.kernel.org list; kvm-ppc@vger.kernel.org > > >> Subject: Re: RFC: proposal for VM reset & shutdown hcall > > >> > > >> > > >> On 01.07.2013, at 23:59, Yoder Stuart-B08248 wrote: > > >> > > >>> For the e500 PV platform we need a VM reset and shutdown > mechanisms. > > >> > > >> CC'ing kvm-ppc@vger. > > >> > > >>> > > >>> > ------------------------------------------------------------------------ > > >>> Hypercall: KVM_HC_VM_RESET > > >>> Description: Requests that the virtual machine be reset. The > > >>> hcall takes no arguments. If successful the hcall > does not > > >>> return. > > >>> > > >>> Arguments: > > >>> r11 hcall-token KVM_HC_VM_RESET > > >>> > > >>> Return values > > >>> r3 status Status of the hcall. If the hcall > succeeds > > >>> it does not return. If an error occurs > > >>> EV_INTERNAL is returned. > > >>> > ------------------------------------------------------------------------ > > >>> Hypercall: KVM_HC_VM_SHUTDOWN > > >>> Description: Requests that the virtual machine be > powered-off/halted. > > >>> The hcall takes no arguments. If successful the > hcall does not > > >>> return. > > >>> > > >>> Arguments: > > >>> r11 hcall-token KVM_HC_VM_SHUTDOWN > > >>> > > >>> Return values > > >>> r3 status Status of the hcall. If the hcall > succeeds > > >>> it does not return. If an error occurs > > >>> EV_INTERNAL is returned. > > >>> > ------------------------------------------------------------------------ > > >>> > > >>> Implementation notes: > > >>> > > >>> -expect hcall token to be defined with KVM_HCALL_TOKEN: > > >>> KVM_HC_VM_RESET > > >>> KVM_HC_VM_SHUTDOWN > > >>> > > >>> -the KVM_HC_FEATURES hcall should be expanded with new feature > bits > > >>> to advertise both new hcalls to the VM: e.g. #define > KVM_FEATURE_VM_RESET > > >> > > >> Do we really need this? Can't we just leave this up to device > tree to tell the guest that this > > feature > > >> exists? After all, it's a pure user space matter whether it > wants to support reboot & shutdown or > > not. > > > > > > I guess there are two questions I have: > > > > > > -does KVM need to advertise to user space that the hcalls exist > through > > > using the KVM_PPC_GET_PVINFO ioctl? > > > > IMHO it should only expose a CAP indicating that it forwards > unknown hcalls to user space. > > So, do we really need a new CAP for that or is that just > assumed...for all > architectures? Yes, we need a new CAP because current kernels don't do that for booke, and QEMU needs to know whether it can advertise the presence of hcalls that rely on it. We also need a well-defined mechanism for doing the forwarding. -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: RFC: proposal for VM reset & shutdown hcall Date: Mon, 1 Jul 2013 18:09:56 -0500 Message-ID: <1372720196.8183.97@snotra> References: <9F6FE96B71CF29479FF1CDC8046E1503632A49@039-SN1MPN1-004.039d.mgd.msft.net> <3B5BAAFB-161D-4D5E-8B01-401E0C8AD72D@suse.de> <9F6FE96B71CF29479FF1CDC8046E1503632A9B@039-SN1MPN1-004.039d.mgd.msft.net> <426615FE-3632-4735-84F4-3F7D5AF143F4@suse.de> <9F6FE96B71CF29479FF1CDC8046E1503632B01@039-SN1MPN1-004.039d.mgd.msft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: Alexander Graf , Bhushan Bharat-R65777 , Wood Scott-B07421 , "kvm@vger.kernel.org list" , "kvm-ppc@vger.kernel.org" To: Yoder Stuart-B08248 Return-path: In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E1503632B01@039-SN1MPN1-004.039d.mgd.msft.net> (from B08248@freescale.com on Mon Jul 1 18:05:55 2013) Content-Disposition: inline Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 07/01/2013 06:05:55 PM, Yoder Stuart-B08248 wrote: > > > > -----Original Message----- > > From: Alexander Graf [mailto:agraf@suse.de] > > Sent: Monday, July 01, 2013 6:01 PM > > To: Yoder Stuart-B08248 > > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org > list; kvm-ppc@vger.kernel.org > > Subject: Re: RFC: proposal for VM reset & shutdown hcall > > > > > > On 02.07.2013, at 00:59, Yoder Stuart-B08248 wrote: > > > > > > > > > > >> -----Original Message----- > > >> From: kvm-ppc-owner@vger.kernel.org > [mailto:kvm-ppc-owner@vger.kernel.org] On Behalf Of Alexander > > Graf > > >> Sent: Monday, July 01, 2013 5:14 PM > > >> To: Yoder Stuart-B08248 > > >> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; > kvm@vger.kernel.org list; kvm-ppc@vger.kernel.org > > >> Subject: Re: RFC: proposal for VM reset & shutdown hcall > > >> > > >> > > >> On 01.07.2013, at 23:59, Yoder Stuart-B08248 wrote: > > >> > > >>> For the e500 PV platform we need a VM reset and shutdown > mechanisms. > > >> > > >> CC'ing kvm-ppc@vger. > > >> > > >>> > > >>> > ------------------------------------------------------------------------ > > >>> Hypercall: KVM_HC_VM_RESET > > >>> Description: Requests that the virtual machine be reset. The > > >>> hcall takes no arguments. If successful the hcall > does not > > >>> return. > > >>> > > >>> Arguments: > > >>> r11 hcall-token KVM_HC_VM_RESET > > >>> > > >>> Return values > > >>> r3 status Status of the hcall. If the hcall > succeeds > > >>> it does not return. If an error occurs > > >>> EV_INTERNAL is returned. > > >>> > ------------------------------------------------------------------------ > > >>> Hypercall: KVM_HC_VM_SHUTDOWN > > >>> Description: Requests that the virtual machine be > powered-off/halted. > > >>> The hcall takes no arguments. If successful the > hcall does not > > >>> return. > > >>> > > >>> Arguments: > > >>> r11 hcall-token KVM_HC_VM_SHUTDOWN > > >>> > > >>> Return values > > >>> r3 status Status of the hcall. If the hcall > succeeds > > >>> it does not return. If an error occurs > > >>> EV_INTERNAL is returned. > > >>> > ------------------------------------------------------------------------ > > >>> > > >>> Implementation notes: > > >>> > > >>> -expect hcall token to be defined with KVM_HCALL_TOKEN: > > >>> KVM_HC_VM_RESET > > >>> KVM_HC_VM_SHUTDOWN > > >>> > > >>> -the KVM_HC_FEATURES hcall should be expanded with new feature > bits > > >>> to advertise both new hcalls to the VM: e.g. #define > KVM_FEATURE_VM_RESET > > >> > > >> Do we really need this? Can't we just leave this up to device > tree to tell the guest that this > > feature > > >> exists? After all, it's a pure user space matter whether it > wants to support reboot & shutdown or > > not. > > > > > > I guess there are two questions I have: > > > > > > -does KVM need to advertise to user space that the hcalls exist > through > > > using the KVM_PPC_GET_PVINFO ioctl? > > > > IMHO it should only expose a CAP indicating that it forwards > unknown hcalls to user space. > > So, do we really need a new CAP for that or is that just > assumed...for all > architectures? Yes, we need a new CAP because current kernels don't do that for booke, and QEMU needs to know whether it can advertise the presence of hcalls that rely on it. We also need a well-defined mechanism for doing the forwarding. -Scott