Re: RFC: proposal for VM reset & shutdown hcall

[Scott Wood <scottwood@freescale.com>]

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