* RFC: proposal for VM reset & shutdown hcall (v2)
@ 2013-07-02 15:07 Yoder Stuart-B08248
2013-07-02 15:23 ` Alexander Graf
0 siblings, 1 reply; 5+ 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@vger.kernel.org
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] 5+ messages in thread* Re: RFC: proposal for VM reset & shutdown hcall (v2)
2013-07-02 15:07 RFC: proposal for VM reset & shutdown hcall (v2) Yoder Stuart-B08248
@ 2013-07-02 15:23 ` Alexander Graf
2013-07-02 15:33 ` Yoder Stuart-B08248
0 siblings, 1 reply; 5+ 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@vger.kernel.org
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] 5+ 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
2013-07-02 16:56 ` Scott Wood
0 siblings, 1 reply; 5+ 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@vger.kernel.org
> -----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] 5+ 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
2013-07-02 19:11 ` Yoder Stuart-B08248
0 siblings, 1 reply; 5+ 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@vger.kernel.org
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] 5+ 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
0 siblings, 0 replies; 5+ 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@vger.kernel.org
> -----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] 5+ messages in thread
end of thread, other threads:[~2013-07-02 19:11 UTC | newest]
Thread overview: 5+ 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:23 ` Alexander Graf
2013-07-02 15:33 ` Yoder Stuart-B08248
2013-07-02 16:56 ` Scott Wood
2013-07-02 19:11 ` Yoder Stuart-B08248
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox