On 02.07.2013, at 01:05, 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? We don't support user space answering ePAPR hcalls today, so it's definitely a CAP. 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
