On 02.07.2013, at 01:09, Scott Wood wrote: > On 07/01/2013 06:05:55 PM, Yoder Stuart-B08248 wrote: >> > -----Original Message----- >> > From: Alexander Graf [mailto:agraf@xxxxxxx] >> > Sent: Monday, July 01, 2013 6:01 PM >> > To: Yoder Stuart-B08248 >> > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@xxxxxxxxxxxxxxx list; kvm-ppc@xxxxxxxxxxxxxxx >> > 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@xxxxxxxxxxxxxxx [mailto:kvm-ppc-owner@xxxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxx list; kvm-ppc@xxxxxxxxxxxxxxx >> > >> 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. We can probably just copy most of the code and documentation from the KVM_EXIT_PAPR_HCALL handling. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
