* RFC: proposal for VM reset & shutdown hcall
@ 2013-07-01 21:59 Yoder Stuart-B08248
2013-07-01 22:13 ` Alexander Graf
0 siblings, 1 reply; 33+ messages in thread
From: Yoder Stuart-B08248 @ 2013-07-01 21:59 UTC (permalink / raw)
To: Bhushan Bharat-R65777, Alexander Graf, Wood Scott-B07421; +Cc: kvm
For the e500 PV platform we need a VM reset and shutdown mechanisms.
------------------------------------------------------------------------
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
Regards,
Stuart
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall
2013-07-01 21:59 RFC: proposal for VM reset & shutdown hcall Yoder Stuart-B08248
@ 2013-07-01 22:13 ` Alexander Graf
0 siblings, 0 replies; 33+ messages in thread
From: Alexander Graf @ 2013-07-01 22:13 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
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.
Alex
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall
@ 2013-07-01 22:13 ` Alexander Graf
0 siblings, 0 replies; 33+ messages in thread
From: Alexander Graf @ 2013-07-01 22:13 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
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.
Alex
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: RFC: proposal for VM reset & shutdown hcall
2013-07-01 22:13 ` Alexander Graf
@ 2013-07-01 22:59 ` Yoder Stuart-B08248
-1 siblings, 0 replies; 33+ messages in thread
From: Yoder Stuart-B08248 @ 2013-07-01 22:59 UTC (permalink / raw)
To: Alexander Graf
Cc: Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
> -----Original Message-----
> From: kvm-ppc-owner@vger.kernel.org [mailto:kvm-ppc-owner@vger.kernel.org] 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@vger.kernel.org list; kvm-ppc@vger.kernel.org
> 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?
-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?
Stuart
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: RFC: proposal for VM reset & shutdown hcall
@ 2013-07-01 22:59 ` Yoder Stuart-B08248
0 siblings, 0 replies; 33+ messages in thread
From: Yoder Stuart-B08248 @ 2013-07-01 22:59 UTC (permalink / raw)
To: Alexander Graf
Cc: Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
> -----Original Message-----
> From: kvm-ppc-owner@vger.kernel.org [mailto:kvm-ppc-owner@vger.kernel.org] 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@vger.kernel.org list; kvm-ppc@vger.kernel.org
> 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?
-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?
Stuart
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall
2013-07-01 22:59 ` Yoder Stuart-B08248
@ 2013-07-01 23:01 ` Alexander Graf
-1 siblings, 0 replies; 33+ messages in thread
From: Alexander Graf @ 2013-07-01 23:01 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
On 02.07.2013, at 00:59, Yoder Stuart-B08248 wrote:
>
>
>> -----Original Message-----
>> From: kvm-ppc-owner@vger.kernel.org [mailto:kvm-ppc-owner@vger.kernel.org] 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@vger.kernel.org list; kvm-ppc@vger.kernel.org
>> 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.
> -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.
Alex
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall
@ 2013-07-01 23:01 ` Alexander Graf
0 siblings, 0 replies; 33+ messages in thread
From: Alexander Graf @ 2013-07-01 23:01 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
On 02.07.2013, at 00:59, Yoder Stuart-B08248 wrote:
>
>
>> -----Original Message-----
>> From: kvm-ppc-owner@vger.kernel.org [mailto:kvm-ppc-owner@vger.kernel.org] 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@vger.kernel.org list; kvm-ppc@vger.kernel.org
>> 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.
> -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.
Alex
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: RFC: proposal for VM reset & shutdown hcall
2013-07-01 22:13 ` Alexander Graf
@ 2013-07-01 23:02 ` Yoder Stuart-B08248
-1 siblings, 0 replies; 33+ messages in thread
From: Yoder Stuart-B08248 @ 2013-07-01 23:02 UTC (permalink / raw)
To: Alexander Graf
Cc: Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
> -----Original Message-----
> From: Yoder Stuart-B08248
> Sent: Monday, July 01, 2013 5:59 PM
> To: 'Alexander Graf'
> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org list; kvm-ppc@vger.kernel.org
> Subject: RE: RFC: proposal for VM reset & shutdown hcall
>
>
>
> > -----Original Message-----
> > From: kvm-ppc-owner@vger.kernel.org [mailto:kvm-ppc-owner@vger.kernel.org] 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@vger.kernel.org list; kvm-ppc@vger.kernel.org
> > 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?
>
> -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?
Sorry, meant: should QEMU advertise this to the guest via a device tree property
or _should KVM advertise_ it via the KVM_HC_FEATURES hcall. What should
KVM_HC_FEATURES be used for?
Stuart
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: RFC: proposal for VM reset & shutdown hcall
@ 2013-07-01 23:02 ` Yoder Stuart-B08248
0 siblings, 0 replies; 33+ messages in thread
From: Yoder Stuart-B08248 @ 2013-07-01 23:02 UTC (permalink / raw)
To: Alexander Graf
Cc: Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
> -----Original Message-----
> From: Yoder Stuart-B08248
> Sent: Monday, July 01, 2013 5:59 PM
> To: 'Alexander Graf'
> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org list; kvm-ppc@vger.kernel.org
> Subject: RE: RFC: proposal for VM reset & shutdown hcall
>
>
>
> > -----Original Message-----
> > From: kvm-ppc-owner@vger.kernel.org [mailto:kvm-ppc-owner@vger.kernel.org] 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@vger.kernel.org list; kvm-ppc@vger.kernel.org
> > 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?
>
> -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?
Sorry, meant: should QEMU advertise this to the guest via a device tree property
or _should KVM advertise_ it via the KVM_HC_FEATURES hcall. What should
KVM_HC_FEATURES be used for?
Stuart
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: RFC: proposal for VM reset & shutdown hcall
2013-07-01 23:01 ` Alexander Graf
@ 2013-07-01 23:05 ` Yoder Stuart-B08248
-1 siblings, 0 replies; 33+ messages in thread
From: Yoder Stuart-B08248 @ 2013-07-01 23:05 UTC (permalink / raw)
To: Alexander Graf
Cc: Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Monday, July 01, 2013 6:01 PM
> To: Yoder Stuart-B08248
> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org list; kvm-ppc@vger.kernel.org
> 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@vger.kernel.org [mailto:kvm-ppc-owner@vger.kernel.org] 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@vger.kernel.org list; kvm-ppc@vger.kernel.org
> >> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: RFC: proposal for VM reset & shutdown hcall
@ 2013-07-01 23:05 ` Yoder Stuart-B08248
0 siblings, 0 replies; 33+ messages in thread
From: Yoder Stuart-B08248 @ 2013-07-01 23:05 UTC (permalink / raw)
To: Alexander Graf
Cc: Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Monday, July 01, 2013 6:01 PM
> To: Yoder Stuart-B08248
> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org list; kvm-ppc@vger.kernel.org
> 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@vger.kernel.org [mailto:kvm-ppc-owner@vger.kernel.org] 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@vger.kernel.org list; kvm-ppc@vger.kernel.org
> >> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall
2013-07-01 23:05 ` Yoder Stuart-B08248
@ 2013-07-01 23:09 ` Scott Wood
-1 siblings, 0 replies; 33+ messages in thread
From: Scott Wood @ 2013-07-01 23:09 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: Alexander Graf, Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
On 07/01/2013 06:05:55 PM, Yoder Stuart-B08248 wrote:
>
>
> > -----Original Message-----
> > From: Alexander Graf [mailto:agraf@suse.de]
> > Sent: Monday, July 01, 2013 6:01 PM
> > To: Yoder Stuart-B08248
> > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org
> list; kvm-ppc@vger.kernel.org
> > 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@vger.kernel.org
> [mailto:kvm-ppc-owner@vger.kernel.org] 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@vger.kernel.org list; kvm-ppc@vger.kernel.org
> > >> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall
@ 2013-07-01 23:09 ` Scott Wood
0 siblings, 0 replies; 33+ messages in thread
From: Scott Wood @ 2013-07-01 23:09 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: Alexander Graf, Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
On 07/01/2013 06:05:55 PM, Yoder Stuart-B08248 wrote:
>
>
> > -----Original Message-----
> > From: Alexander Graf [mailto:agraf@suse.de]
> > Sent: Monday, July 01, 2013 6:01 PM
> > To: Yoder Stuart-B08248
> > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org
> list; kvm-ppc@vger.kernel.org
> > 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@vger.kernel.org
> [mailto:kvm-ppc-owner@vger.kernel.org] 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@vger.kernel.org list; kvm-ppc@vger.kernel.org
> > >> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall
2013-07-01 23:05 ` Yoder Stuart-B08248
@ 2013-07-01 23:11 ` Alexander Graf
-1 siblings, 0 replies; 33+ messages in thread
From: Alexander Graf @ 2013-07-01 23:11 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
On 02.07.2013, at 01:05, Yoder Stuart-B08248 wrote:
>
>
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Monday, July 01, 2013 6:01 PM
>> To: Yoder Stuart-B08248
>> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org list; kvm-ppc@vger.kernel.org
>> 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@vger.kernel.org [mailto:kvm-ppc-owner@vger.kernel.org] 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@vger.kernel.org list; kvm-ppc@vger.kernel.org
>>>> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall
@ 2013-07-01 23:11 ` Alexander Graf
0 siblings, 0 replies; 33+ messages in thread
From: Alexander Graf @ 2013-07-01 23:11 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
On 02.07.2013, at 01:05, Yoder Stuart-B08248 wrote:
>
>
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Monday, July 01, 2013 6:01 PM
>> To: Yoder Stuart-B08248
>> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org list; kvm-ppc@vger.kernel.org
>> 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@vger.kernel.org [mailto:kvm-ppc-owner@vger.kernel.org] 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@vger.kernel.org list; kvm-ppc@vger.kernel.org
>>>> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall
2013-07-01 23:09 ` Scott Wood
@ 2013-07-01 23:12 ` Alexander Graf
-1 siblings, 0 replies; 33+ messages in thread
From: Alexander Graf @ 2013-07-01 23:12 UTC (permalink / raw)
To: Scott Wood
Cc: Yoder Stuart-B08248, Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
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@suse.de]
>> > Sent: Monday, July 01, 2013 6:01 PM
>> > To: Yoder Stuart-B08248
>> > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org list; kvm-ppc@vger.kernel.org
>> > 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@vger.kernel.org [mailto:kvm-ppc-owner@vger.kernel.org] 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@vger.kernel.org list; kvm-ppc@vger.kernel.org
>> > >> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall
@ 2013-07-01 23:12 ` Alexander Graf
0 siblings, 0 replies; 33+ messages in thread
From: Alexander Graf @ 2013-07-01 23:12 UTC (permalink / raw)
To: Scott Wood
Cc: Yoder Stuart-B08248, Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
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@suse.de]
>> > Sent: Monday, July 01, 2013 6:01 PM
>> > To: Yoder Stuart-B08248
>> > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org list; kvm-ppc@vger.kernel.org
>> > 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@vger.kernel.org [mailto:kvm-ppc-owner@vger.kernel.org] 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@vger.kernel.org list; kvm-ppc@vger.kernel.org
>> > >> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* RFC: proposal for VM reset & shutdown hcall (v2)
2013-07-01 22:13 ` Alexander Graf
@ 2013-07-02 15:07 ` Yoder Stuart-B08248
-1 siblings, 0 replies; 33+ messages in thread
From: Yoder Stuart-B08248 @ 2013-07-02 15:07 UTC (permalink / raw)
To: Bhushan Bharat-R65777, Alexander Graf, Wood Scott-B07421
Cc: kvm@vger.kernel.org list, kvm-ppc
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
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[].
------------------------------------------------------------------------
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
Value type: <none>
Definition: If the property is present the hypervisor supports
the KVM_HC_VM_RESET hcall.
Property name: has-shutdown
Value type: <none>
Definition: If the property is present the hypervisor supports
the KVM_HC_VM_SHUTDOWN hcall.
------------------------------------------------------------------------
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.
Regards,
Stuart
^ permalink raw reply [flat|nested] 33+ messages in thread
* RFC: proposal for VM reset & shutdown hcall (v2)
@ 2013-07-02 15:07 ` Yoder Stuart-B08248
0 siblings, 0 replies; 33+ messages in thread
From: Yoder Stuart-B08248 @ 2013-07-02 15:07 UTC (permalink / raw)
To: Bhushan Bharat-R65777, Alexander Graf, Wood Scott-B07421
Cc: kvm@vger.kernel.org list, kvm-ppc
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
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[].
------------------------------------------------------------------------
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
Value type: <none>
Definition: If the property is present the hypervisor supports
the KVM_HC_VM_RESET hcall.
Property name: has-shutdown
Value type: <none>
Definition: If the property is present the hypervisor supports
the KVM_HC_VM_SHUTDOWN hcall.
------------------------------------------------------------------------
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.
Regards,
Stuart
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall (v2)
2013-07-02 15:07 ` Yoder Stuart-B08248
@ 2013-07-02 15:23 ` Alexander Graf
-1 siblings, 0 replies; 33+ messages in thread
From: Alexander Graf @ 2013-07-02 15:23 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
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.
>
> ------------------------------------------------------------------------
> 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?
Thanks a lot for writing all of this down :)
Alex
> Value type:<none>
> Definition: If the property is present the hypervisor supports
> the KVM_HC_VM_RESET hcall.
>
> Property name: has-shutdown
> Value type:<none>
> Definition: If the property is present the hypervisor supports
> the KVM_HC_VM_SHUTDOWN hcall.
>
> ------------------------------------------------------------------------
> 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.
>
>
>
> Regards,
> Stuart
>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall (v2)
@ 2013-07-02 15:23 ` Alexander Graf
0 siblings, 0 replies; 33+ messages in thread
From: Alexander Graf @ 2013-07-02 15:23 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
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.
>
> ------------------------------------------------------------------------
> 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?
Thanks a lot for writing all of this down :)
Alex
> Value type:<none>
> Definition: If the property is present the hypervisor supports
> the KVM_HC_VM_RESET hcall.
>
> Property name: has-shutdown
> Value type:<none>
> Definition: If the property is present the hypervisor supports
> the KVM_HC_VM_SHUTDOWN hcall.
>
> ------------------------------------------------------------------------
> 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.
>
>
>
> Regards,
> Stuart
>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: RFC: proposal for VM reset & shutdown hcall (v2)
2013-07-02 15:23 ` Alexander Graf
@ 2013-07-02 15:33 ` Yoder Stuart-B08248
-1 siblings, 0 replies; 33+ messages in thread
From: Yoder Stuart-B08248 @ 2013-07-02 15:33 UTC (permalink / raw)
To: Alexander Graf
Cc: Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Tuesday, July 02, 2013 10:23 AM
> To: Yoder Stuart-B08248
> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org list; kvm-ppc@vger.kernel.org
> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: RFC: proposal for VM reset & shutdown hcall (v2)
@ 2013-07-02 15:33 ` Yoder Stuart-B08248
0 siblings, 0 replies; 33+ messages in thread
From: Yoder Stuart-B08248 @ 2013-07-02 15:33 UTC (permalink / raw)
To: Alexander Graf
Cc: Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Tuesday, July 02, 2013 10:23 AM
> To: Yoder Stuart-B08248
> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org list; kvm-ppc@vger.kernel.org
> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall (v2)
2013-07-02 15:33 ` Yoder Stuart-B08248
@ 2013-07-02 16:56 ` Scott Wood
-1 siblings, 0 replies; 33+ messages in thread
From: Scott Wood @ 2013-07-02 16:56 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: Alexander Graf, Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
On 07/02/2013 10:33:58 AM, Yoder Stuart-B08248 wrote:
>
>
> > -----Original Message-----
> > From: Alexander Graf [mailto:agraf@suse.de]
> > Sent: Tuesday, July 02, 2013 10:23 AM
> > To: Yoder Stuart-B08248
> > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org
> list; kvm-ppc@vger.kernel.org
> > Subject: Re: RFC: proposal for VM reset & shutdown hcall (v2)
> >
> > On 07/02/2013 05:07 PM, Yoder Stuart-B08248 wrote:
> > >
> ------------------------------------------------------------------------
> > > 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.
kvm,has-reset and kvm,has-shutdown would be more stylistically correct.
This assumes that we're going to put this in Documentation/virtual/kvm/
-- otherwise the prefix should be "qemu".
-Scott
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall (v2)
@ 2013-07-02 16:56 ` Scott Wood
0 siblings, 0 replies; 33+ messages in thread
From: Scott Wood @ 2013-07-02 16:56 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: Alexander Graf, Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
On 07/02/2013 10:33:58 AM, Yoder Stuart-B08248 wrote:
>
>
> > -----Original Message-----
> > From: Alexander Graf [mailto:agraf@suse.de]
> > Sent: Tuesday, July 02, 2013 10:23 AM
> > To: Yoder Stuart-B08248
> > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org
> list; kvm-ppc@vger.kernel.org
> > Subject: Re: RFC: proposal for VM reset & shutdown hcall (v2)
> >
> > On 07/02/2013 05:07 PM, Yoder Stuart-B08248 wrote:
> > >
> ------------------------------------------------------------------------
> > > 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.
kvm,has-reset and kvm,has-shutdown would be more stylistically correct.
This assumes that we're going to put this in Documentation/virtual/kvm/
-- otherwise the prefix should be "qemu".
-Scott
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: RFC: proposal for VM reset & shutdown hcall (v2)
2013-07-02 16:56 ` Scott Wood
@ 2013-07-02 19:11 ` Yoder Stuart-B08248
-1 siblings, 0 replies; 33+ messages in thread
From: Yoder Stuart-B08248 @ 2013-07-02 19:11 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: Alexander Graf, Bhushan Bharat-R65777, kvm@vger.kernel.org list, kvm-ppc
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, July 02, 2013 11:56 AM
> To: Yoder Stuart-B08248
> Cc: Alexander Graf; Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org list; kvm-
> ppc@vger.kernel.org
> Subject: Re: RFC: proposal for VM reset & shutdown hcall (v2)
>
> On 07/02/2013 10:33:58 AM, Yoder Stuart-B08248 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Alexander Graf [mailto:agraf@suse.de]
> > > Sent: Tuesday, July 02, 2013 10:23 AM
> > > To: Yoder Stuart-B08248
> > > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org
> > list; kvm-ppc@vger.kernel.org
> > > Subject: Re: RFC: proposal for VM reset & shutdown hcall (v2)
> > >
> > > On 07/02/2013 05:07 PM, Yoder Stuart-B08248 wrote:
> > > >
> > ------------------------------------------------------------------------
> > > > 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.
>
> kvm,has-reset and kvm,has-shutdown would be more stylistically correct.
>
> This assumes that we're going to put this in Documentation/virtual/kvm/
> -- otherwise the prefix should be "qemu".
Will make it "kvm,"
Stuart
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: RFC: proposal for VM reset & shutdown hcall (v2)
@ 2013-07-02 19:11 ` Yoder Stuart-B08248
0 siblings, 0 replies; 33+ messages in thread
From: Yoder Stuart-B08248 @ 2013-07-02 19:11 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: Alexander Graf, Bhushan Bharat-R65777, kvm@vger.kernel.org list, kvm-ppc
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, July 02, 2013 11:56 AM
> To: Yoder Stuart-B08248
> Cc: Alexander Graf; Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org list; kvm-
> ppc@vger.kernel.org
> Subject: Re: RFC: proposal for VM reset & shutdown hcall (v2)
>
> On 07/02/2013 10:33:58 AM, Yoder Stuart-B08248 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Alexander Graf [mailto:agraf@suse.de]
> > > Sent: Tuesday, July 02, 2013 10:23 AM
> > > To: Yoder Stuart-B08248
> > > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org
> > list; kvm-ppc@vger.kernel.org
> > > Subject: Re: RFC: proposal for VM reset & shutdown hcall (v2)
> > >
> > > On 07/02/2013 05:07 PM, Yoder Stuart-B08248 wrote:
> > > >
> > ------------------------------------------------------------------------
> > > > 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.
>
> kvm,has-reset and kvm,has-shutdown would be more stylistically correct.
>
> This assumes that we're going to put this in Documentation/virtual/kvm/
> -- otherwise the prefix should be "qemu".
Will make it "kvm,"
Stuart
^ permalink raw reply [flat|nested] 33+ messages in thread
* RFC: proposal for VM reset & shutdown hcall (v3)
2013-07-01 22:13 ` Alexander Graf
@ 2013-07-02 22:08 ` Yoder Stuart-B08248
-1 siblings, 0 replies; 33+ messages in thread
From: Yoder Stuart-B08248 @ 2013-07-02 22:08 UTC (permalink / raw)
To: Bhushan Bharat-R65777, Alexander Graf, Wood Scott-B07421
Cc: kvm@vger.kernel.org list, kvm-ppc
Version 3 changes
-added "kvm," prefix to hcall properties in device tree
-specified which registers ret and args will end up in
-removed e500-specific comments
------------------------------------------------------------------------
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 Power/PowerPC platforms that support ePAPR hcalls.
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[]. As per the ePAPR hcall ABI, the return value
should be returned to the guest in R3 and output return values
in R4 - R10.
------------------------------------------------------------------------
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 in the device tree passed to the VM.
Property name: kvm,has-reset
Value type: <none>
Definition: If the property is present the hypervisor supports
the KVM_HC_VM_RESET hcall.
Property name: kvm,has-shutdown
Value type: <none>
Definition: If the property is present the hypervisor supports
the KVM_HC_VM_SHUTDOWN hcall.
------------------------------------------------------------------------
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.
Regards,
Stuart
^ permalink raw reply [flat|nested] 33+ messages in thread
* RFC: proposal for VM reset & shutdown hcall (v3)
@ 2013-07-02 22:08 ` Yoder Stuart-B08248
0 siblings, 0 replies; 33+ messages in thread
From: Yoder Stuart-B08248 @ 2013-07-02 22:08 UTC (permalink / raw)
To: Bhushan Bharat-R65777, Alexander Graf, Wood Scott-B07421
Cc: kvm@vger.kernel.org list, kvm-ppc
Version 3 changes
-added "kvm," prefix to hcall properties in device tree
-specified which registers ret and args will end up in
-removed e500-specific comments
------------------------------------------------------------------------
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 Power/PowerPC platforms that support ePAPR hcalls.
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[]. As per the ePAPR hcall ABI, the return value
should be returned to the guest in R3 and output return values
in R4 - R10.
------------------------------------------------------------------------
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 in the device tree passed to the VM.
Property name: kvm,has-reset
Value type: <none>
Definition: If the property is present the hypervisor supports
the KVM_HC_VM_RESET hcall.
Property name: kvm,has-shutdown
Value type: <none>
Definition: If the property is present the hypervisor supports
the KVM_HC_VM_SHUTDOWN hcall.
------------------------------------------------------------------------
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.
Regards,
Stuart
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall (v3)
2013-07-02 22:08 ` Yoder Stuart-B08248
@ 2013-07-02 22:13 ` Scott Wood
-1 siblings, 0 replies; 33+ messages in thread
From: Scott Wood @ 2013-07-02 22:13 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: Bhushan Bharat-R65777, Alexander Graf, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
On 07/02/2013 05:08:02 PM, Yoder Stuart-B08248 wrote:
> ------------------------------------------------------------------------
> KVM_EXIT_EPAPR_HCALL exit definition
>
> /* KVM_EXIT_EPAPR_HCALL */
> struct {
> __u64 nr;
> __u64 ret;
> __u64 args[8];
> } epapr_hcall;
>
> This is used on Power/PowerPC platforms that support ePAPR hcalls.
> 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[]. As per the ePAPR hcall ABI, the return value
> should be returned to the guest in R3 and output return values
> in R4 - R10.
Should we specify that KVM fills in upper half of each value with zero
if the target is not in 64-bit mode?
-Scott
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall (v3)
@ 2013-07-02 22:13 ` Scott Wood
0 siblings, 0 replies; 33+ messages in thread
From: Scott Wood @ 2013-07-02 22:13 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: Bhushan Bharat-R65777, Alexander Graf, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
On 07/02/2013 05:08:02 PM, Yoder Stuart-B08248 wrote:
> ------------------------------------------------------------------------
> KVM_EXIT_EPAPR_HCALL exit definition
>
> /* KVM_EXIT_EPAPR_HCALL */
> struct {
> __u64 nr;
> __u64 ret;
> __u64 args[8];
> } epapr_hcall;
>
> This is used on Power/PowerPC platforms that support ePAPR hcalls.
> 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[]. As per the ePAPR hcall ABI, the return value
> should be returned to the guest in R3 and output return values
> in R4 - R10.
Should we specify that KVM fills in upper half of each value with zero
if the target is not in 64-bit mode?
-Scott
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall (v3)
2013-07-02 22:13 ` Scott Wood
@ 2013-07-02 22:19 ` Alexander Graf
-1 siblings, 0 replies; 33+ messages in thread
From: Alexander Graf @ 2013-07-02 22:19 UTC (permalink / raw)
To: Scott Wood
Cc: Yoder Stuart-B08248, Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
On 03.07.2013, at 00:13, Scott Wood wrote:
> On 07/02/2013 05:08:02 PM, Yoder Stuart-B08248 wrote:
>> ------------------------------------------------------------------------
>> KVM_EXIT_EPAPR_HCALL exit definition
>> /* KVM_EXIT_EPAPR_HCALL */
>> struct {
>> __u64 nr;
>> __u64 ret;
>> __u64 args[8];
>> } epapr_hcall;
>> This is used on Power/PowerPC platforms that support ePAPR hcalls.
Just call it "PowerPC". That should be good enough for every platform. No need to mention POWER separately.
>> 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[]. As per the ePAPR hcall ABI, the return value
>> should be returned to the guest in R3 and output return values
>> in R4 - R10.
>
> Should we specify that KVM fills in upper half of each value with zero if the target is not in 64-bit mode?
Yeah, better to be precise.
Alex
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: RFC: proposal for VM reset & shutdown hcall (v3)
@ 2013-07-02 22:19 ` Alexander Graf
0 siblings, 0 replies; 33+ messages in thread
From: Alexander Graf @ 2013-07-02 22:19 UTC (permalink / raw)
To: Scott Wood
Cc: Yoder Stuart-B08248, Bhushan Bharat-R65777, Wood Scott-B07421,
kvm@vger.kernel.org list, kvm-ppc
On 03.07.2013, at 00:13, Scott Wood wrote:
> On 07/02/2013 05:08:02 PM, Yoder Stuart-B08248 wrote:
>> ------------------------------------------------------------------------
>> KVM_EXIT_EPAPR_HCALL exit definition
>> /* KVM_EXIT_EPAPR_HCALL */
>> struct {
>> __u64 nr;
>> __u64 ret;
>> __u64 args[8];
>> } epapr_hcall;
>> This is used on Power/PowerPC platforms that support ePAPR hcalls.
Just call it "PowerPC". That should be good enough for every platform. No need to mention POWER separately.
>> 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[]. As per the ePAPR hcall ABI, the return value
>> should be returned to the guest in R3 and output return values
>> in R4 - R10.
>
> Should we specify that KVM fills in upper half of each value with zero if the target is not in 64-bit mode?
Yeah, better to be precise.
Alex
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2013-07-02 22:19 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-02 15:07 RFC: proposal for VM reset & shutdown hcall (v2) Yoder Stuart-B08248
2013-07-02 15:07 ` Yoder Stuart-B08248
2013-07-02 15:23 ` Alexander Graf
2013-07-02 15:23 ` Alexander Graf
2013-07-02 15:33 ` Yoder Stuart-B08248
2013-07-02 15:33 ` Yoder Stuart-B08248
2013-07-02 16:56 ` Scott Wood
2013-07-02 16:56 ` Scott Wood
2013-07-02 19:11 ` Yoder Stuart-B08248
2013-07-02 19:11 ` Yoder Stuart-B08248
-- strict thread matches above, loose matches on Subject: below --
2013-07-02 22:08 RFC: proposal for VM reset & shutdown hcall (v3) Yoder Stuart-B08248
2013-07-02 22:08 ` Yoder Stuart-B08248
2013-07-02 22:13 ` Scott Wood
2013-07-02 22:13 ` Scott Wood
2013-07-02 22:19 ` Alexander Graf
2013-07-02 22:19 ` Alexander Graf
2013-07-01 21:59 RFC: proposal for VM reset & shutdown hcall Yoder Stuart-B08248
2013-07-01 22:13 ` Alexander Graf
2013-07-01 22:13 ` Alexander Graf
2013-07-01 22:59 ` Yoder Stuart-B08248
2013-07-01 22:59 ` Yoder Stuart-B08248
2013-07-01 23:01 ` Alexander Graf
2013-07-01 23:01 ` Alexander Graf
2013-07-01 23:05 ` Yoder Stuart-B08248
2013-07-01 23:05 ` Yoder Stuart-B08248
2013-07-01 23:09 ` Scott Wood
2013-07-01 23:09 ` Scott Wood
2013-07-01 23:12 ` Alexander Graf
2013-07-01 23:12 ` Alexander Graf
2013-07-01 23:11 ` Alexander Graf
2013-07-01 23:11 ` Alexander Graf
2013-07-01 23:02 ` Yoder Stuart-B08248
2013-07-01 23:02 ` Yoder Stuart-B08248
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.