> -----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? > > -should QEMU advertise this to the guest via a device tree property > > or via the KVM_HC_FEATURES hcall. What should KVM_HC_FEATURES be used for? > > At least today user space doesn't have influence on the KVM_HC_FEATURES hcall. I think that one simply > predates the ePAPR way of enumerating hypercall availability through device tree. Ok, I'll respin the proposal exposing via the device tree. Stuart -- 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
