> -----Original Message----- > From: Alexander Graf [mailto:agraf@xxxxxxx] > Sent: Tuesday, July 02, 2013 10:23 AM > 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 (v2) > > On 07/02/2013 05:07 PM, Yoder Stuart-B08248 wrote: > > Version 2 changes > > -remove advertising via KVM_HC_FEATURES > > -define a new exit type (KVM_EXIT_EPAPR_HCALL) for user space > > handled hcalls > > -advertise KVM_EXIT_EPAPR_HCALL to user space via new capability > > flag > > -defined device tree properties to advertise the existence > > of reset and shutdown hcalls to a guest > > > > ------------------------------------------------------------------------ > > KVM_CAP_EXIT_EPAPR_HCALL Capability > > > > A new capability KVM_CAP_EXIT_EPAPR_HCALL is defined to advertise > > the new KVM_EXIT_EPAPR_HCALL exit . > > > > ------------------------------------------------------------------------ > > KVM_EXIT_EPAPR_HCALL exit definition > > > > /* KVM_EXIT_EPAPR_HCALL */ > > struct { > > __u64 nr; > > __u64 ret; > > __u64 args[8]; > > } epapr_hcall; > > > > This is used on e500 Power Architecture for the paravirt e500 > > It can also be used on book3s systems. We use the same logic for -M > g3beige and -M mac99. We even use it for -M mpc8544ds. > > > platform. It occurs when a guest does a hypercall (as defined > > in the ePAPR 1.1) and the hcall is not handled by the kernel. > > > > The 'nr' field contains the hypercall number (from the guest R11), > > and 'args' contains the arguments (from the guest R3 - R10). > > Userspace should put the return code in 'ret' and any extra returned > > values in args[]. > > Please specify which registers ret and args will end up in. ok > > ------------------------------------------------------------------------ > > Advertising reset and shutdown in device tree. > > > > A virtual machine can detect the availability of the reset > > and shutdown hcalls by looking at properties on the /hypervisor > > node. > > > > Property name: has-reset > > I don't remember how ePAPR specifies this. Aren't keys in /hypervisor > supposed to be common throughout hypervisors? So if Windriver wants to > add a reset hypercall, they'd also add "has-reset"? How does the guest > know which hcall number to issue? ePAPR does not define how additional hypervisor specific properties are defined. Since these are KVM-specific hcalls we should probably not name these generically and call them kvm-has-reset and kvm-has-shutdown. The hcalls numbers are defined in the KVM-specific number space, _not_ the ePAPR-hcall number space. Other hypervisors like the Freescale Embedded hypervisor already define their own 'private' hcalls for reset. 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
