On 15.02.2013, at 00:59, Paul Mackerras wrote: > From: Michael Ellerman <mich...@ellerman.id.au> > > 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 <mich...@ellerman.id.au> > Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> > Signed-off-by: Paul Mackerras <pau...@samba.org> > --- > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
