Re: RFC: proposal for VM reset & shutdown hcall

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux