Re: [PATCH 1/9] KVM: PPC: Book3S: Add infrastructure to implement kernel-side RTAS calls

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

 



On 15.02.2013, at 00:59, Paul Mackerras wrote:

> From: Michael Ellerman <michael@xxxxxxxxxxxxxx>
> 
> For pseries machine emulation, in order to move the interrupt
> controller code to the kernel, we need to intercept some RTAS
> calls in the kernel itself.  This adds an infrastructure to allow
> in-kernel handlers to be registered for RTAS services by name.
> A new ioctl, KVM_PPC_RTAS_DEFINE_TOKEN, then allows userspace to
> associate token values with those service names.  Then, when the
> guest requests an RTAS service with one of those token values, it
> will be handled by the relevant in-kernel handler rather than being
> passed up to userspace as at present.
> 
> Signed-off-by: Michael Ellerman <michael@xxxxxxxxxxxxxx>
> Signed-off-by: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Paul Mackerras <paulus@xxxxxxxxx>
> ---
> Documentation/virtual/kvm/api.txt   |   19 ++++
> arch/powerpc/include/asm/hvcall.h   |    3 +
> arch/powerpc/include/asm/kvm_host.h |    1 +
> arch/powerpc/include/asm/kvm_ppc.h  |    4 +
> arch/powerpc/include/uapi/asm/kvm.h |    6 ++
> arch/powerpc/kvm/Makefile           |    1 +
> arch/powerpc/kvm/book3s_hv.c        |   18 +++-
> arch/powerpc/kvm/book3s_pr_papr.c   |    7 ++
> arch/powerpc/kvm/book3s_rtas.c      |  182 +++++++++++++++++++++++++++++++++++
> arch/powerpc/kvm/powerpc.c          |    9 +-
> include/uapi/linux/kvm.h            |    3 +
> 11 files changed, 251 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/kvm/book3s_rtas.c
> 
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index c2534c3..d3e2d60 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -2122,6 +2122,25 @@ header; first `n_valid' valid entries with contents from the data
> written, then `n_invalid' invalid entries, invalidating any previously
> valid entries found.
> 
> +4.79 KVM_PPC_RTAS_DEFINE_TOKEN
> +
> +Capability: KVM_CAP_PPC_RTAS
> +Architectures: ppc
> +Type: vm ioctl
> +Parameters: struct kvm_rtas_token_args
> +Returns: 0 on success, -1 on error
> +
> +Defines a token value for a RTAS (Run Time Abstraction Services)
> +service in order to allow it to be handled in the kernel.  The
> +argument struct gives the name of the service, which must be the name
> +of a service that has a kernel-side implementation.  If the token
> +value is non-zero, it will be associated with that service, and
> +subsequent RTAS calls by the guest specifying that token will be
> +handled by the kernel.  If the token value is 0, then any token
> +associated with the service will be forgotten, and subsequent RTAS
> +calls by the guest for that service will be passed to userspace to be
> +handled.
> +
> 
> 5. The kvm_run structure
> ------------------------
> diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
> index 7a86706..9ea22b2 100644
> --- a/arch/powerpc/include/asm/hvcall.h
> +++ b/arch/powerpc/include/asm/hvcall.h
> @@ -269,6 +269,9 @@
> #define H_GET_MPP_X		0x314
> #define MAX_HCALL_OPCODE	H_GET_MPP_X
> 
> +/* Platform specific hcalls, used by KVM */
> +#define H_RTAS			0xf000

How about you define a different hcall ID for this? Then QEMU would create its "rtas entry blob" such that KVM-routed RTAS handling goes to KVM directly.


Alex

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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