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.
-Scott
--
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
