All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Yoder Stuart-B08248 <B08248@freescale.com>
Cc: Bhushan Bharat-R65777 <R65777@freescale.com>,
	Wood Scott-B07421 <B07421@freescale.com>,
	"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
	"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>
Subject: Re: RFC: proposal for VM reset & shutdown hcall (v2)
Date: Tue, 02 Jul 2013 15:23:11 +0000	[thread overview]
Message-ID: <51D2F05F.6020202@suse.de> (raw)
In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E150363308E@039-SN1MPN1-004.039d.mgd.msft.net>

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


WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Yoder Stuart-B08248 <B08248@freescale.com>
Cc: Bhushan Bharat-R65777 <R65777@freescale.com>,
	Wood Scott-B07421 <B07421@freescale.com>,
	"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
	"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>
Subject: Re: RFC: proposal for VM reset & shutdown hcall (v2)
Date: Tue, 02 Jul 2013 17:23:11 +0200	[thread overview]
Message-ID: <51D2F05F.6020202@suse.de> (raw)
In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E150363308E@039-SN1MPN1-004.039d.mgd.msft.net>

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

  reply	other threads:[~2013-07-02 15:23 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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
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 [this message]
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
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51D2F05F.6020202@suse.de \
    --to=agraf@suse.de \
    --cc=B07421@freescale.com \
    --cc=B08248@freescale.com \
    --cc=R65777@freescale.com \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.