kvm tools: Generate SPAPR PPC64 guest device tree
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH 1/8 kvm tools: Add initial SPAPR PPC64 architecture support
This patch adds a new arch directory, powerpc, basic file structure, register setup and where necessary stubs out arch-specific functions (e.g. interrupts, runloop exits) that later patches will provide. The target is an SPAPR-compliant PPC64 machine (i.e. pSeries); there is no support for PPC32 or 'bare metal' PPC64 guests as yet. Subsequent patches implement the hcalls and RTAS required to boot SPAPR pSeries kernels.
Memory is mapped from hugetlbfs (as that is currently required by upstream PPC64 HV-mode KVM). The mapping of a VRMA region is yet to be implemented; this is only necessary on processors that don't support VRMA, e.g. <= P6. Work is therefore needed to get this going on pre-P7 CPUs.
Processor state is set up as a guest kernel would expect (both primary and secondaries), and SMP is fully supported.
Finally, support is added for simply loading flat binary kernels (plus initrd). (bzImages are not used on PPC, and this series does not add zImage support or an ELF loader.) The intention is to later support loading firmware such as SLOF.
--- tools/kvm/Makefile | 10 + tools/kvm/kvm.c | 3 + tools/kvm/powerpc/include/kvm/barrier.h | 6 + tools/kvm/powerpc/include/kvm/kvm-arch.h | 70 ++++++++ tools/kvm/powerpc/include/kvm/kvm-cpu-arch.h | 46 +++++ tools/kvm/powerpc/ioport.c | 18 ++ tools/kvm/powerpc/irq.c | 40 +++++ tools/kvm/powerpc/kvm-cpu.c | 232 ++++++++++++++++++++++++++ tools/kvm/powerpc/kvm.c | 231 +++++++++++++++++++++++++ 9 files changed, 656 insertions(+), 0 deletions(-) create mode 100644 tools/kvm/powerpc/include/kvm/barrier.h create mode 100644 tools/kvm/powerpc/include/kvm/kvm-arch.h create mode 100644 tools/kvm/powerpc/include/kvm/kvm-cpu-arch.h create mode 100644 tools/kvm/powerpc/ioport.c create mode 100644 tools/kvm/powerpc/irq.c create mode 100644 tools/kvm/powerpc/kvm-cpu.c create mode 100644 tools/kvm/powerpc/kvm.c
tools/kvm/Makefile +10 -0
@@ -121,6 +121,16 @@ ifeq ($(ARCH),x86) OTHEROBJS += x86/bios/bios-rom.o ARCH_INCLUDE := x86/include endif +# POWER/ppc: Actually only support ppc64 currently. +ifeq ($(uname_M), ppc64) + DEFINES += -DCONFIG_PPC + OBJS += powerpc/ioport.o + OBJS += powerpc/irq.o + OBJS += powerpc/kvm.o + OBJS += powerpc/kvm-cpu.o + ARCH_INCLUDE := powerpc/include + CFLAGS += -m64 +endif ###
tools/kvm/kvm.c +3 -0
@@ -49,6 +49,9 @@ const char *kvm_exit_reasons[] = {DEFINE_KVM_EXIT_REASON (KVM_EXIT_DCR ),DEFINE_KVM_EXIT_REASON (KVM_EXIT_NMI ),DEFINE_KVM_EXIT_REASON (KVM_EXIT_INTERNAL_ERROR ), +#ifdef CONFIG_PPC64 + DEFINE_KVM_EXIT_REASON(KVM_EXIT_PAPR_HCALL), +#endif };extern struct kvm *kvm;
tools/kvm/powerpc/include/kvm/barrier.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _KVM_BARRIER_H_ +#define _KVM_BARRIER_H_ + +#include <asm/system.h> + +#endif /* _KVM_BARRIER_H_ */
tools/kvm/powerpc/include/kvm/kvm-arch.h new file +70 -0
70 lines not on this page · raw message
tools/kvm/powerpc/include/kvm/kvm-cpu-arch.h new file +46 -0
46 lines not on this page · raw message
tools/kvm/powerpc/ioport.c new file +18 -0
@@ -0,0 +1,18 @@ +/* +* PPC64 ioport platform setup. There isn't any! :-) +* +* Copyright 2011 Matt Evans <[email protected]>, IBM Corporation. +* +* This program is free software; you can redistribute it and/or modify it +* under the terms of the GNU General Public License version 2 as published +* by the Free Software Foundation. +*/ + +#include "kvm/ioport.h" + +#include <stdlib.h> + +void ioport__setup_arch (void ) +{ +/* PPC has no legacy ioports to set up */ +}
tools/kvm/powerpc/irq.c new file +40 -0
@@ -0,0 +1,40 @@ +/* +* PPC64 IRQ routines +* +* Copyright 2011 Matt Evans <[email protected]>, IBM Corporation. +* +* This program is free software; you can redistribute it and/or modify it +* under the terms of the GNU General Public License version 2 as published +* by the Free Software Foundation. +*/ + +#include "kvm/irq.h" +#include "kvm/kvm.h" +#include "kvm/util.h" + +#include <linux/types.h> +#include <linux/rbtree.h> +#include <linux/list.h> +#include <linux/kvm.h> +#include <sys/ioctl.h> + +#include <stddef.h> +#include <stdlib.h> + +int irq__register_device (u32 dev,u8 *num,u8 *pin,u8 *line) +{ +fprintf (stderr,"irq__register_device(%d, [%d], [%d], [%d]\n" , + dev, *num, *pin, *line); +return 0 ; +} + +void irq__init (struct kvm *kvm) +{ +fprintf (stderr, __func__); +} + +int irq__add_msix_route (struct kvm *kvm,struct msi_msg *msg) +{ +die (__FUNCTION__); +return 0 ; +}
tools/kvm/powerpc/kvm-cpu.c new file +232 -0
232 lines not on this page · raw message
tools/kvm/powerpc/kvm.c new file +231 -0
231 lines not on this page · raw message
Re: [PATCH 1/8] kvm tools: Add initial SPAPR PPC64 architecture support
Quoted 6 lines · Matt Evans
This patch adds a new arch directory, powerpc, basic file structure, register setup and where necessary stubs out arch-specific functions (e.g. interrupts, runloop exits) that later patches will provide. The target is an SPAPR-compliant PPC64 machine (i.e. pSeries); there is no support for PPC32 or 'bare metal' PPC64 guests as yet. Subsequent patches implement the hcalls and RTAS required to boot SPAPR pSeries kernels.
You just sent out 28 patches removing "everything is x86" dependencies -- may I suggest that the PPC code be structured so that there isn't an "everything on PPC (or even PPC64) is SPAPR" assumption, even if SPAPR is initially the only sub-arch present?
E.g. this is SPAPR-specific despite being in generically-named tools/kvm/powerpc/kvm-cpu.c:
Quoted 36 lines
tools/kvm/powerpc/kvm-cpu.c new file +17
-0+static void kvm_cpu__setup_regs (struct kvm_cpu *vcpu) +{ +struct kvm_regs *r = &vcpu->regs; + +if (vcpu->cpu_id ==0 ) { + r->pc =KERNEL_START_ADDR ; + r->gpr[3 ] = vcpu->kvm->fdt_gra; + r->gpr[5 ] =0 ; + }else { + r->pc =KERNEL_SECONDARY_START_ADDR ; + r->gpr[3 ] = vcpu->cpu_id; + } + r->msr =0x8000000000001000UL ;/* 64bit, non-HV, ME */ + +if (ioctl (vcpu->vcpu_fd,KVM_SET_REGS , &vcpu->regs) <0 ) +die_perror ("KVM_SET_REGS failed" ); +}tools/kvm/powerpc/include/kvm/kvm-arch.h new file +12
-0@@ -0,0 +1,70 @@ +/* +* PPC64 architecture-specific definitions +* +* Copyright 2011 Matt Evans <[email protected]>, IBM Corporation. +* +* This program is free software; you can redistribute it and/or modify it +* under the terms of the GNU General Public License version 2 as published +* by the Free Software Foundation. +*/ + +#ifndef KVM__KVM_ARCH_H +#define KVM__KVM_ARCH_H
[snip]
Quoted 1 line
+void
ioport__setup_arch(void)
[snip]
Quoted 1 line
+int
irq__register_device(u32 dev, u8 *num, u8 *pin, u8 *line)
I'm seeing a lot of double-underscores -- is this common style in KVM tool? It's reserved for use by the compiler and system library. It's common in the kernel (though not used like this for namespace prefixes), but there's no system library involved there.
Quoted 5 lines
tools/kvm/powerpc/kvm-cpu.c new file +0
-0
[snip]
Quoted 8 lines
tools/kvm/powerpc/kvm-cpu.c new file +8
-0+#define MSR_SF (1UL<<63) +#define MSR_HV (1UL<<60) +#define MSR_VEC (1UL<<25) +#define MSR_VSX (1UL<<23) +#define MSR_POW (1UL<<18) +#define MSR_EE (1UL<<15) +#define MSR_PR (1UL<<14) +#define MSR_FP (1UL<<13)
tools/kvm/powerpc/kvm-cpu.c line 44
Quoted 10 lines
tools/kvm/powerpc/kvm-cpu.c new file +10
-0+#define MSR_ME (1UL<<12) +#define MSR_FE0 (1UL<<11) +#define MSR_SE (1UL<<10) +#define MSR_BE (1UL<<9) +#define MSR_FE1 (1UL<<8) +#define MSR_IR (1UL<<5) +#define MSR_DR (1UL<<4) +#define MSR_PMM (1UL<<2) +#define MSR_RI (1UL<<1) +#define MSR_LE (1UL<<0)
Shouldn't these go in a header?
Quoted 1 line
+#define
HUGETLBFS_MAGIC0x958458f6
#include <linux/magic.h>
?
-Scott
Re: [PATCH 1/8] kvm tools: Add initial SPAPR PPC64 architecture support
Quoted 4 lines · Scott Wood
I'm seeing a lot of double-underscores -- is this common style in KVM tool? It's reserved for use by the compiler and system library. It's common in the kernel (though not used like this for namespace prefixes), but there's no system library involved there.
Yes, they are KVM tool coding style which we took from perf. Double underscore _prefixes_ are reserved in userspace but there's no reason we can't use them in identifiers like we do.
Pekka
Re: [PATCH 1/8] kvm tools: Add initial SPAPR PPC64 architecture support
Quoted 9 lines · Pekka Enberg
Quoted 4 lines · Scott Wood
I'm seeing a lot of double-underscores -- is this common style in KVM tool? It's reserved for use by the compiler and system library. It's common in the kernel (though not used like this for namespace prefixes), but there's no system library involved there.
Yes, they are KVM tool coding style which we took from perf. Double underscore _prefixes_ are reserved in userspace but there's no reason we can't use them in identifiers like we do.
OK, it looks like it's just C++ that also reserves non-leading double underscores -- sorry about that.
-Scott
Re: [PATCH 1/8] kvm tools: Add initial SPAPR PPC64 architecture support
In reply to Scott WoodHi Scott,
Quoted 8 lines · Scott Wood
Quoted 6 lines · Matt Evans
This patch adds a new arch directory, powerpc, basic file structure, register setup and where necessary stubs out arch-specific functions (e.g. interrupts, runloop exits) that later patches will provide. The target is an SPAPR-compliant PPC64 machine (i.e. pSeries); there is no support for PPC32 or 'bare metal' PPC64 guests as yet. Subsequent patches implement the hcalls and RTAS required to boot SPAPR pSeries kernels.
Quoted 4 lines
You just sent out 28 patches removing "everything is x86" dependencies -- may I suggest that the PPC code be structured so that there isn't an "everything on PPC (or even PPC64) is SPAPR" assumption, even if SPAPR is initially the only sub-arch present?
I had anticipated this comment (though not the "28 patches" remark, easy now). It is a fair comment, but you hit the nail on the head with your other mail (regarding configuring in i8042, presumably to emulate crappy dev boards) asking whether kvmtool has a config system. It does not.
Since we currently lack any kind of build-time configuration (or any fancy run-time -M <machine> a la QEMU) it's a bit hard to cater for multiple platforms. I'm aware that the PPC patches are painfully PPC64-with-SPAPR and I don't present them as perfect, but I really think we need to attack the configuration stuff before bifurcating. Is this something you'd like to see to?
(Your comments on the #defines and magic accepted & fixed, thank you.)
Cheers,
Matt
Quoted 84 lines
E.g. this is SPAPR-specific despite being in generically-named
tools/kvm/powerpc/kvm-cpu.c:Quoted 36 lines
tools/kvm/powerpc/kvm-cpu.c new file +17
-0+static void kvm_cpu__setup_regs (struct kvm_cpu *vcpu) +{ +struct kvm_regs *r = &vcpu->regs; + +if (vcpu->cpu_id ==0 ) { + r->pc =KERNEL_START_ADDR ; + r->gpr[3 ] = vcpu->kvm->fdt_gra; + r->gpr[5 ] =0 ; + }else { + r->pc =KERNEL_SECONDARY_START_ADDR ; + r->gpr[3 ] = vcpu->cpu_id; + } + r->msr =0x8000000000001000UL ;/* 64bit, non-HV, ME */ + +if (ioctl (vcpu->vcpu_fd,KVM_SET_REGS , &vcpu->regs) <0 ) +die_perror ("KVM_SET_REGS failed" ); +}tools/kvm/powerpc/include/kvm/kvm-arch.h new file +12
-0@@ -0,0 +1,70 @@ +/* +* PPC64 architecture-specific definitions +* +* Copyright 2011 Matt Evans <[email protected]>, IBM Corporation. +* +* This program is free software; you can redistribute it and/or modify it +* under the terms of the GNU General Public License version 2 as published +* by the Free Software Foundation. +*/ + +#ifndef KVM__KVM_ARCH_H +#define KVM__KVM_ARCH_H [snip]
Quoted 1 line
+void
ioport__setup_arch(void)[snip]
Quoted 1 line
+int
irq__register_device(u32 dev, u8 *num, u8 *pin, u8 *line)I'm seeing a lot of double-underscores -- is this common style in KVM tool? It's reserved for use by the compiler and system library. It's common in the kernel (though not used like this for namespace prefixes), but there's no system library involved there.
Quoted 5 lines
tools/kvm/powerpc/kvm-cpu.c new file +0
-0[snip]
Quoted 8 lines
tools/kvm/powerpc/kvm-cpu.c new file +8
-0+#define MSR_SF (1UL<<63) +#define MSR_HV (1UL<<60) +#define MSR_VEC (1UL<<25) +#define MSR_VSX (1UL<<23) +#define MSR_POW (1UL<<18) +#define MSR_EE (1UL<<15) +#define MSR_PR (1UL<<14) +#define MSR_FP (1UL<<13)tools/kvm/powerpc/kvm-cpu.c line 44
Quoted 10 lines
tools/kvm/powerpc/kvm-cpu.c new file +10
-0+#define MSR_ME (1UL<<12) +#define MSR_FE0 (1UL<<11) +#define MSR_SE (1UL<<10) +#define MSR_BE (1UL<<9) +#define MSR_FE1 (1UL<<8) +#define MSR_IR (1UL<<5) +#define MSR_DR (1UL<<4) +#define MSR_PMM (1UL<<2) +#define MSR_RI (1UL<<1) +#define MSR_LE (1UL<<0)Shouldn't these go in a header?
Quoted 1 line
+#define
HUGETLBFS_MAGIC0x958458f6#include <
linux/magic.h>?
-Scott
Re: [PATCH 1/8] kvm tools: Add initial SPAPR PPC64 architecture support
Quoted 11 lines · Matt Evans
Hi Scott,
Quoted 8 lines · Scott Wood
Quoted 6 lines · Matt Evans
This patch adds a new arch directory, powerpc, basic file structure, register setup and where necessary stubs out arch-specific functions (e.g. interrupts, runloop exits) that later patches will provide. The target is an SPAPR-compliant PPC64 machine (i.e. pSeries); there is no support for PPC32 or 'bare metal' PPC64 guests as yet. Subsequent patches implement the hcalls and RTAS required to boot SPAPR pSeries kernels.
Quoted 6 lines
Quoted 4 lines
You just sent out 28 patches removing "everything is x86" dependencies -- may I suggest that the PPC code be structured so that there isn't an "everything on PPC (or even PPC64) is SPAPR" assumption, even if SPAPR is initially the only sub-arch present?
I had anticipated this comment (though not the "28 patches" remark, easy now).
I was just using that to illustrate how it's easier to handle earlier than later -- no offense intended. :-)
Quoted 9 lines
It is a fair comment, but you hit the nail on the head with your other mail (regarding configuring in i8042, presumably to emulate crappy dev boards) asking whether kvmtool has a config system. It does not.
Since we currently lack any kind of build-time configuration (or any fancy run-time -M <machine> a la QEMU) it's a bit hard to cater for multiple platforms. I'm aware that the PPC patches are painfully PPC64-with-SPAPR and I don't present them as perfect, but I really think we need to attack the configuration stuff before bifurcating. Is this something you'd like to see to?
Just putting all SPAPR stuff in SPAPR-named files (or at least SPAPR-named functions), and likewise for book3s stuff, etc. would be an improvement. I see that you did this for some things, but not all. Try to make it obvious where the target-specific branching would take place, even if the actual branching mechanism is currently just a FIXME comment.
-Scott
Re: [PATCH 1/8] kvm tools: Add initial SPAPR PPC64 architecture support
Quoted 32 lines · Scott Wood
Quoted 11 lines · Matt Evans
Hi Scott,
Quoted 8 lines · Scott Wood
Quoted 6 lines · Matt Evans
This patch adds a new arch directory, powerpc, basic file structure, register setup and where necessary stubs out arch-specific functions (e.g. interrupts, runloop exits) that later patches will provide. The target is an SPAPR-compliant PPC64 machine (i.e. pSeries); there is no support for PPC32 or 'bare metal' PPC64 guests as yet. Subsequent patches implement the hcalls and RTAS required to boot SPAPR pSeries kernels.
Quoted 6 lines
Quoted 4 lines
You just sent out 28 patches removing "everything is x86" dependencies -- may I suggest that the PPC code be structured so that there isn't an "everything on PPC (or even PPC64) is SPAPR" assumption, even if SPAPR is initially the only sub-arch present?
I had anticipated this comment (though not the "28 patches" remark, easy now).
I was just using that to illustrate how it's easier to handle earlier than later -- no offense intended. :-)
Quoted 9 lines
It is a fair comment, but you hit the nail on the head with your other mail (regarding configuring in i8042, presumably to emulate crappy dev boards) asking whether kvmtool has a config system. It does not.
Since we currently lack any kind of build-time configuration (or any fancy run-time -M <machine> a la QEMU) it's a bit hard to cater for multiple platforms. I'm aware that the PPC patches are painfully PPC64-with-SPAPR and I don't present them as perfect, but I really think we need to attack the configuration stuff before bifurcating. Is this something you'd like to see to?
Quoted 5 lines
Just putting all SPAPR stuff in SPAPR-named files (or at least SPAPR-named functions), and likewise for book3s stuff, etc. would be an improvement. I see that you did this for some things, but not all. Try to make it obvious where the target-specific branching would take place, even if the actual branching mechanism is currently just a FIXME comment.
No worries, that's a good suggestion-- I'll have a spin through the PPC stuff and see if there's anything worth splitting, or at least point out everywhere I can find with an appropriate comment.
Thanks,
Matt
PATCH 2/8 kvm tools: Generate SPAPR PPC64 guest device tree
In reply to a message not in the archiveThe generated DT is the bare minimum structure required for SPAPR (on which subsequent patches for VIO, XICS, PCI etc. will build); root node, cpus, memory.
Some aspects are currently hardwired for simplicity, for example advertised page sizes, HPT size, SLB size, VMX/DFP, etc. Future support of a variety of POWER CPUs should acquire this info from the host and encode appropriately.
This requires a 64-bit libfdt.
--- tools/kvm/Makefile | 3 +- tools/kvm/powerpc/kvm.c | 141 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 143 insertions(+), 1 deletions(-)
tools/kvm/Makefile +2 -1
@@ -129,7 +129,8 @@ ifeq ($(uname_M), ppc64) OBJS += powerpc/kvm.o OBJS += powerpc/kvm-cpu.o ARCH_INCLUDE := powerpc/include - CFLAGS += -m64 + CFLAGS += -m64 + LIBS += -lfdt endif ###
tools/kvm/powerpc/kvm.c +141 -0
164 lines not on this page · raw message
PATCH 3/8 kvm tools: Add SPAPR PPC64 hcall & rtascall structure
In reply to a message not in the archiveThis patch adds the basic structure for HV calls, their registration and some of the simpler calls. A similar layout for RTAS calls is also added, again with some of the simpler RTAS calls used by the guest. The SPAPR RTAS stub is generated inline. Also, nodes for RTAS are added to the device tree.
--- tools/kvm/Makefile | 2 + tools/kvm/powerpc/kvm-cpu.c | 5 + tools/kvm/powerpc/kvm.c | 39 +++++- tools/kvm/powerpc/spapr.h | 308 +++++++++++++++++++++++++++++++++++++++ tools/kvm/powerpc/spapr_hcall.c | 151 +++++++++++++++++++ tools/kvm/powerpc/spapr_rtas.c | 226 ++++++++++++++++++++++++++++ 6 files changed, 730 insertions(+), 1 deletions(-) create mode 100644 tools/kvm/powerpc/spapr.h create mode 100644 tools/kvm/powerpc/spapr_hcall.c create mode 100644 tools/kvm/powerpc/spapr_rtas.c
tools/kvm/Makefile +2 -0
@@ -128,6 +128,8 @@ ifeq ($(uname_M), ppc64) OBJS += powerpc/irq.o OBJS += powerpc/kvm.o OBJS += powerpc/kvm-cpu.o + OBJS += powerpc/spapr_hcall.o + OBJS += powerpc/spapr_rtas.o ARCH_INCLUDE := powerpc/include CFLAGS += -m64 LIBS += -lfdt
tools/kvm/powerpc/kvm-cpu.c +5 -0
@@ -14,6 +14,8 @@#include "kvm/util.h" #include "kvm/kvm.h" +#include "spapr.h" +#include <sys/ioctl.h> #include <sys/mman.h> #include <signal.h>
@@ -156,6 +158,9 @@ bool kvm_cpu__handle_exit(struct kvm_cpu *vcpu)bool ret = true;struct kvm_run *run = vcpu->kvm_run;switch (run->exit_reason) { +case KVM_EXIT_PAPR_HCALL : + run->papr_hcall.ret =spapr_hypercall (vcpu, run->papr_hcall.nr, run->papr_hcall.args); +break ;default : ret = false; }
tools/kvm/powerpc/kvm.c +38 -1
@@ -14,6 +14,8 @@#include "kvm/kvm.h" #include "kvm/util.h" +#include "spapr.h" +#include <linux/kvm.h> #include <sys/types.h>
@@ -153,6 +155,10 @@ void kvm__arch_init(struct kvm *kvm, const char *kvm_dev, const char *hugetlbfs_ cap_ppc_rma =ioctl (kvm->sys_fd,KVM_CHECK_EXTENSION ,KVM_CAP_PPC_RMA );if (cap_ppc_rma ==2 )die ("Need contiguous RMA allocation on this hardware, which is not yet supported." ); + +/* Do these before FDT setup, IRQ setup, etc. */ +hypercall_init (); +register_core_rtas (); }void kvm__irq_line (struct kvm *kvm,int irq,int level)
@@ -262,6 +268,20 @@ static void setup_fdt(struct kvm *kvm)_FDT (fdt_property_cell (fdt,"#address-cells" ,0x2 ));_FDT (fdt_property_cell (fdt,"#size-cells" ,0x2 )); +/* RTAS */ +_FDT (fdt_begin_node (fdt,"rtas" )); +/* This is what the kernel uses to switch 'We're an LPAR'! */ +_FDT (fdt_property (fdt,"ibm,hypertas-functions" , hypertas_prop_kvm, +sizeof (hypertas_prop_kvm))); +_FDT (fdt_property_cell (fdt,"linux,rtas-base" , kvm->rtas_gra)); +_FDT (fdt_property_cell (fdt,"linux,rtas-entry" , kvm->rtas_gra)); +_FDT (fdt_property_cell (fdt,"rtas-size" , kvm->rtas_size)); +/* Now add properties for all RTAS tokens: */ +if (spapr_rtas_fdt_setup (kvm, fdt)) +die ("Couldn't create RTAS FDT properties\n" ); + +_FDT (fdt_end_node (fdt)); +/* /chosen */ _FDT (fdt_begin_node (fdt,"chosen" ));/* cmdline */
@@ -363,7 +383,24 @@ static void setup_fdt(struct kvm *kvm)*/ void kvm__arch_setup_firmware (struct kvm *kvm) { -/* Load RTAS */ +/* Set up RTAS stub. All it is is a single hypercall: +0: 7c 64 1b 78 mr r4,r3 +4: 3c 60 00 00 lis r3,0 +8: 60 63 f0 00 ori r3,r3,61440 +c: 44 00 00 22 sc 1 +10: 4e 80 00 20 blr +*/ +uint32_t *rtas =guest_flat_to_host (kvm, kvm->rtas_gra); + + rtas[0 ] =0x7c641b78 ; + rtas[1 ] =0x3c600000 ; + rtas[2 ] =0x6063f000 ; + rtas[3 ] =0x44000022 ; + rtas[4 ] =0x4e800020 ; + kvm->rtas_size =20 ; + +pr_info ("Set up %ld bytes of RTAS at 0x%lx\n" , + kvm->rtas_size, kvm->rtas_gra);/* Load SLOF */
tools/kvm/powerpc/spapr.h new file +308 -0
308 lines not on this page · raw message
tools/kvm/powerpc/spapr_hcall.c new file +151 -0
151 lines not on this page · raw message
tools/kvm/powerpc/spapr_rtas.c new file +226 -0
226 lines not on this page · raw message
PATCH 4/8 kvm tools: Add SPAPR PPC64 HV console
In reply to a message not in the archiveThis adds the console code, plus VIO HV terminal nodes are added to the device tree so the guest kernel will pick it up.
--- tools/kvm/Makefile | 1 + tools/kvm/powerpc/kvm.c | 31 ++++++++++++ tools/kvm/powerpc/spapr_hvcons.c | 101 ++++++++++++++++++++++++++++++++++++++ tools/kvm/powerpc/spapr_hvcons.h | 19 +++++++ 4 files changed, 152 insertions(+), 0 deletions(-) create mode 100644 tools/kvm/powerpc/spapr_hvcons.c create mode 100644 tools/kvm/powerpc/spapr_hvcons.h
tools/kvm/Makefile +1 -0
@@ -130,6 +130,7 @@ ifeq ($(uname_M), ppc64) OBJS += powerpc/kvm-cpu.o OBJS += powerpc/spapr_hcall.o OBJS += powerpc/spapr_rtas.o + OBJS += powerpc/spapr_hvcons.o ARCH_INCLUDE := powerpc/include CFLAGS += -m64 LIBS += -lfdt
tools/kvm/powerpc/kvm.c +31 -0
@@ -15,6 +15,7 @@#include "kvm/util.h" #include "spapr.h" +#include "spapr_hvcons.h" #include <linux/kvm.h>
@@ -159,6 +160,8 @@ void kvm__arch_init(struct kvm *kvm, const char *kvm_dev, const char *hugetlbfs_/* Do these before FDT setup, IRQ setup, etc. */ hypercall_init ();register_core_rtas (); +/* Now that hypercalls are initialised, register a couple for the console: */ +spapr_hvcons_init (); }void kvm__irq_line (struct kvm *kvm,int irq,int level)
@@ -172,6 +175,11 @@ void kvm__irq_trigger(struct kvm *kvm, int irq)kvm__irq_line (kvm, irq,0 ); } +void kvm__arch_periodic_poll (struct kvm *kvm) +{ +spapr_hvcons_poll (kvm); +} +int load_flat_binary (struct kvm *kvm,int fd_kernel,int fd_initrd,const char *kernel_cmdline) {void *p;
@@ -297,6 +305,13 @@ static void setup_fdt(struct kvm *kvm) &ird_end_prop, sizeof(ird_end_prop))); } +/* stdout-path: This is assuming we're using the HV console. Also, the +* address is hardwired until we do a VIO bus. +*/ +_FDT (fdt_property_string (fdt,"linux,stdout-path" , +"/vdevice/vty@30000000" )); +_FDT (fdt_end_node (fdt)); +/* Memory: We don't alloc. a separate RMA yet. If we ever need to * (CAP_PPC_RMA == 2) then have one memory node for 0->RMAsize, and * another RMAsize->endOfMem.
@@ -369,6 +384,22 @@ static void setup_fdt(struct kvm *kvm) }_FDT (fdt_end_node (fdt)); +/* VIO: See comment in linux,stdout-path; we don't yet represent a VIO +* bus/address allocation so addresses are hardwired here. +*/ +_FDT (fdt_begin_node (fdt,"vdevice" )); +_FDT (fdt_property_cell (fdt,"#address-cells" ,0x1 )); +_FDT (fdt_property_cell (fdt,"#size-cells" ,0x0 )); +_FDT (fdt_property_string (fdt,"device_type" ,"vdevice" )); +_FDT (fdt_property_string (fdt,"compatible" ,"IBM,vdevice" )); +_FDT (fdt_begin_node (fdt,"vty@30000000" )); +_FDT (fdt_property_string (fdt,"name" ,"vty" )); +_FDT (fdt_property_string (fdt,"device_type" ,"serial" )); +_FDT (fdt_property_string (fdt,"compatible" ,"hvterm1" )); +_FDT (fdt_property_cell (fdt,"reg" ,0x30000000 )); +_FDT (fdt_end_node (fdt)); +_FDT (fdt_end_node (fdt)); +/* Finalise: */ _FDT (fdt_end_node (fdt));/* Root node */ _FDT (fdt_finish (fdt));
tools/kvm/powerpc/spapr_hvcons.c new file +101 -0
101 lines not on this page · raw message
tools/kvm/powerpc/spapr_hvcons.h new file +19 -0
@@ -0,0 +1,19 @@ +/* +* SPAPR HV console +* +* Copyright (c) 2011 Matt Evans <[email protected]>, IBM Corporation. +* +* This program is free software; you can redistribute it and/or modify it +* under the terms of the GNU General Public License version 2 as published +* by the Free Software Foundation. +*/ + +#ifndef spapr_hvcons_H +#define spapr_hvcons_H + +#include "kvm/kvm.h" + +void spapr_hvcons_init (void ); +void spapr_hvcons_poll (struct kvm *kvm); + +#endif
PATCH 5/8 kvm tools: Add PPC64 XICS interrupt controller support
In reply to a message not in the archiveThis patch adds XICS emulation code (heavily borrowed from QEMU), and wires this into kvm_cpu__irq() to fire a CPU IRQ via KVM. A device tree entry is also added. IPIs work, xics_alloc_irqnum() is added to allocate an external IRQ (which will later be used by the PHB PCI code) and finally, kvm__irq_line() can be called to raise an IRQ on XICS.
--- tools/kvm/Makefile | 1 + tools/kvm/powerpc/include/kvm/kvm-arch.h | 1 + tools/kvm/powerpc/include/kvm/kvm-cpu-arch.h | 2 + tools/kvm/powerpc/irq.c | 11 +- tools/kvm/powerpc/kvm-cpu.c | 10 + tools/kvm/powerpc/kvm.c | 25 +- tools/kvm/powerpc/xics.c | 529 ++++++++++++++++++++++++++ tools/kvm/powerpc/xics.h | 23 ++ 8 files changed, 596 insertions(+), 6 deletions(-) create mode 100644 tools/kvm/powerpc/xics.c create mode 100644 tools/kvm/powerpc/xics.h
tools/kvm/Makefile +1 -0
@@ -131,6 +131,7 @@ ifeq ($(uname_M), ppc64) OBJS += powerpc/spapr_hcall.o OBJS += powerpc/spapr_rtas.o OBJS += powerpc/spapr_hvcons.o + OBJS += powerpc/xics.o ARCH_INCLUDE := powerpc/include CFLAGS += -m64 LIBS += -lfdt
tools/kvm/powerpc/include/kvm/kvm-arch.h +1 -0
@@ -65,6 +65,7 @@ struct kvm {unsigned long initrd_gra;unsigned long initrd_size;const char *name; + struct icp_state *icp; };#endif /* KVM__KVM_ARCH_H */
tools/kvm/powerpc/include/kvm/kvm-cpu-arch.h +2 -0
@@ -17,6 +17,8 @@#include <pthread.h> +#define POWER7_EXT_IRQ 0 +struct kvm ;struct kvm_cpu {
tools/kvm/powerpc/irq.c +10 -1
@@ -21,6 +21,10 @@#include <stddef.h> #include <stdlib.h> +#include "xics.h" + +#define XICS_IRQS 1024 +int irq__register_device (u32 dev,u8 *num,u8 *pin,u8 *line) { fprintf(stderr, "irq__register_device(%d, [%d], [%d], [%d]\n",
@@ -30,7 +34,12 @@ int irq__register_device(u32 dev, u8 *num, u8 *pin, u8 *line)void irq__init (struct kvm *kvm) { -fprintf (stderr, __func__); +/* kvm->nr_cpus is now valid; for /now/, pass +* this to xics_system_init(), which assumes servers +* are numbered 0..nrcpus. This may not really be true, +* but it is OK currently. +*/ + kvm->icp =xics_system_init (XICS_IRQS , kvm->nrcpus); }int irq__add_msix_route (struct kvm *kvm,struct msi_msg *msg)
tools/kvm/powerpc/kvm-cpu.c +10 -0
@@ -15,6 +15,7 @@#include "kvm/kvm.h" #include "spapr.h" +#include "xics.h" #include <sys/ioctl.h> #include <sys/mman.h>
@@ -107,6 +108,9 @@ struct kvm_cpu *kvm_cpu__init(struct kvm *kvm, unsigned long cpu_id)*/ vcpu->is_running = true; +/* Register with IRQ controller */ +xics_cpu_register (vcpu); +return vcpu; }
@@ -151,6 +155,12 @@ void kvm_cpu__reset_vcpu(struct kvm_cpu *vcpu)/* kvm_cpu__irq - set KVM's IRQ flag on this vcpu */ void kvm_cpu__irq (struct kvm_cpu *vcpu,int pin,int level) { +unsigned int virq = level ?KVM_INTERRUPT_SET_LEVEL :KVM_INTERRUPT_UNSET ; + +if (pin !=POWER7_EXT_IRQ ) +return ; +if (ioctl (vcpu->vcpu_fd,KVM_INTERRUPT , &virq) <0 ) +pr_warning ("Could not KVM_INTERRUPT." ); }bool kvm_cpu__handle_exit (struct kvm_cpu *vcpu)
tools/kvm/powerpc/kvm.c +20 -5
@@ -41,9 +41,13 @@#define HUGETLBFS_PATH "/var/lib/hugetlbfs/global/pagesize-16MB/" +#define PHANDLE_XICP 0x00001111 +static char kern_cmdline[2048 ];struct kvm_ext kvm_req_ext[] = { + {DEFINE_KVM_EXT (KVM_CAP_PPC_UNSET_IRQ ) }, + {DEFINE_KVM_EXT (KVM_CAP_PPC_IRQ_LEVEL ) }, {0 ,0 } };
@@ -164,11 +168,6 @@ void kvm__arch_init(struct kvm *kvm, const char *kvm_dev, const char *hugetlbfs_spapr_hvcons_init (); } -void kvm__irq_line (struct kvm *kvm,int irq,int level) -{ -fprintf (stderr,"irq_line(%d, %d)\n" , irq, level); -} -void kvm__irq_trigger (struct kvm *kvm,int irq) {kvm__irq_line (kvm, irq,1 );
@@ -384,6 +383,22 @@ static void setup_fdt(struct kvm *kvm) }_FDT (fdt_end_node (fdt)); +/* IRQ controller */ +_FDT (fdt_begin_node (fdt,"interrupt-controller@0" )); + +_FDT (fdt_property_string (fdt,"device_type" , +"PowerPC-External-Interrupt-Presentation" )); +_FDT (fdt_property_string (fdt,"compatible" ,"IBM,ppc-xicp" )); +_FDT (fdt_property_cell (fdt,"reg" ,0 )); +_FDT (fdt_property (fdt,"interrupt-controller" ,NULL ,0 )); +_FDT (fdt_property (fdt,"ibm,interrupt-server-ranges" , + interrupt_server_ranges_prop, +sizeof (interrupt_server_ranges_prop))); +_FDT (fdt_property_cell (fdt,"#interrupt-cells" ,2 )); +_FDT (fdt_property_cell (fdt,"linux,phandle" ,PHANDLE_XICP )); +_FDT (fdt_property_cell (fdt,"phandle" ,PHANDLE_XICP )); +_FDT (fdt_end_node (fdt)); +/* VIO: See comment in linux,stdout-path; we don't yet represent a VIO * bus/address allocation so addresses are hardwired here. */
tools/kvm/powerpc/xics.c new file +529 -0
529 lines not on this page · raw message
tools/kvm/powerpc/xics.h new file +23 -0
@@ -0,0 +1,23 @@ +/* +* PAPR Virtualized Interrupt System, aka ICS/ICP aka xics +* +* Copyright 2011 Matt Evans <[email protected]>, IBM Corporation. +* +* This program is free software; you can redistribute it and/or modify it +* under the terms of the GNU General Public License version 2 as published +* by the Free Software Foundation. +*/ + +#ifndef XICS_H +#define XICS_H + +#define XICS_IPI 0x2 + +struct kvm_cpu ; +struct icp_state ; + +struct icp_state *xics_system_init (unsigned int nr_irqs,unsigned int nr_cpus); +void xics_cpu_register (struct kvm_cpu *vcpu); +int xics_alloc_irqnum (void ); + +#endif
PATCH 6/8 kvm tools: Add PPC64 PCI Host Bridge
In reply to a message not in the archiveThis provides the PCI bridge, definitions for the address layout of the windows and wires in IRQs. Once PCI devices are all registered, they are enumerated and DT nodes generated for each.
--- tools/kvm/powerpc/include/kvm/kvm-arch.h | 3 + tools/kvm/powerpc/irq.c | 17 +- tools/kvm/powerpc/kvm.c | 11 + tools/kvm/powerpc/spapr.h | 8 + tools/kvm/powerpc/spapr_pci.c | 429 ++++++++++++++++++++++++++++++ tools/kvm/powerpc/spapr_pci.h | 38 +++ 6 files changed, 504 insertions(+), 2 deletions(-) create mode 100644 tools/kvm/powerpc/spapr_pci.c create mode 100644 tools/kvm/powerpc/spapr_pci.h
tools/kvm/powerpc/include/kvm/kvm-arch.h +3 -0
@@ -40,6 +40,8 @@*/ #define KVM_PCI_MMIO_AREA 0x1000000 +struct spapr_phb ; +struct kvm {int sys_fd;/* For system ioctls(), i.e. /dev/kvm */ int vm_fd;/* For VM ioctls() */
@@ -66,6 +68,7 @@ struct kvm {unsigned long initrd_size;const char *name;struct icp_state *icp; + struct spapr_phb *phb; };#endif /* KVM__KVM_ARCH_H */
tools/kvm/powerpc/irq.c +15 -2
@@ -21,14 +21,27 @@#include <stddef.h> #include <stdlib.h> +#include "kvm/pci.h" +#include "xics.h" +#include "spapr_pci.h" #define XICS_IRQS 1024 +static int pci_devs =0 ; +int irq__register_device (u32 dev,u8 *num,u8 *pin,u8 *line) { -fprintf (stderr,"irq__register_device(%d, [%d], [%d], [%d]\n" , - dev, *num, *pin, *line); +if (pci_devs >=PCI_MAX_DEVICES ) +die ("Hit PCI device limit!\n" ); + + *num = pci_devs++; + + *pin =1 ; +/* Have I said how nasty I find this? Line should be dontcare... PHB +* should determine which CPU/XICS IRQ to fire. +*/ + *line =xics_alloc_irqnum ();return 0 ; }
tools/kvm/powerpc/kvm.c +11 -0
@@ -16,6 +16,7 @@#include "spapr.h" #include "spapr_hvcons.h" +#include "spapr_pci.h" #include <linux/kvm.h>
@@ -166,6 +167,11 @@ void kvm__arch_init(struct kvm *kvm, const char *kvm_dev, const char *hugetlbfs_register_core_rtas ();/* Now that hypercalls are initialised, register a couple for the console: */ spapr_hvcons_init (); +spapr_create_phb (kvm,"pci" ,SPAPR_PCI_BUID , +SPAPR_PCI_MEM_WIN_ADDR , +SPAPR_PCI_MEM_WIN_SIZE , +SPAPR_PCI_IO_WIN_ADDR , +SPAPR_PCI_IO_WIN_SIZE ); }void kvm__irq_trigger (struct kvm *kvm,int irq)
@@ -420,6 +426,11 @@ static void setup_fdt(struct kvm *kvm)_FDT (fdt_finish (fdt));_FDT (fdt_open_into (fdt, fdt_dest,FDT_MAX_SIZE )); + +/* PCI */ +if (spapr_populate_pci_devices (kvm,PHANDLE_XICP , fdt_dest)) +die ("Fail populating PCI device nodes" ); +_FDT (fdt_add_mem_rsv (fdt_dest, kvm->rtas_gra, kvm->rtas_size));_FDT (fdt_pack (fdt_dest)); }
tools/kvm/powerpc/spapr.h +8 -0
@@ -305,4 +305,12 @@ target_ulong spapr_rtas_call(struct kvm_cpu *vcpu, uint32_t token, uint32_t nargs, target_ulong args, uint32_t nret, target_ulong rets); +#define SPAPR_PCI_BUID 0x800000020000001ULL +#define SPAPR_PCI_MEM_WIN_ADDR (KVM_MMIO_START + 0xA0000000) +#define SPAPR_PCI_MEM_WIN_SIZE 0x20000000 +#define SPAPR_PCI_IO_WIN_ADDR (KVM_MMIO_START + 0x80000000) +/* This, to me, is odd... 32MB of I/O? Some PHBs are set up like this. +* Anything ever use > 64K? :P */ +#define SPAPR_PCI_IO_WIN_SIZE 0x2000000 +#endif /* !defined (__HW_SPAPR_H__) */
tools/kvm/powerpc/spapr_pci.c new file +429 -0
429 lines not on this page · raw message
tools/kvm/powerpc/spapr_pci.h new file +38 -0
@@ -0,0 +1,38 @@ +/* +* SPAPR PHB definitions +* +* Modifications by Matt Evans <[email protected]>, IBM Corporation. +* +* This program is free software; you can redistribute it and/or modify it +* under the terms of the GNU General Public License version 2 as published +* by the Free Software Foundation. +*/ + +#ifndef SPAPR_PCI_H +#define SPAPR_PCI_H + +#include "kvm/kvm.h" +#include <inttypes.h> + +/* With XICS, we can easily accomodate 1 IRQ per PCI device. */ + +#define SPAPR_PCI_NUM_LSI 256 + +struct spapr_phb { +uint64_t buid; +uint64_t mem_addr; +uint64_t mem_size; +uint64_t io_addr; +uint64_t io_size; +}; + +void spapr_create_phb (struct kvm *kvm, +const char *busname,uint64_t buid, +uint64_t mem_win_addr,uint64_t mem_win_size, +uint64_t io_win_addr,uint64_t io_win_size); + +int spapr_populate_pci_devices (struct kvm *kvm, +uint32_t xics_phandle, +void *fdt); + +#endif
PATCH 7/8 kvm tools: Add PPC64 kvm_cpu__emulate_io()
In reply to a message not in the archiveThis is the final piece of the puzzle for PPC SPAPR PCI; this function splits MMIO accesses into the two PHB windows & directs things to MMIO/IO emulation as appropriate.
--- tools/kvm/Makefile | 1 + tools/kvm/powerpc/kvm-cpu.c | 34 ++++++++++++++++++++++++++++++++++ 2 files changed, 35 insertions(+), 0 deletions(-)
tools/kvm/Makefile +1 -0
@@ -131,6 +131,7 @@ ifeq ($(uname_M), ppc64) OBJS += powerpc/spapr_hcall.o OBJS += powerpc/spapr_rtas.o OBJS += powerpc/spapr_hvcons.o + OBJS += powerpc/spapr_pci.o OBJS += powerpc/xics.o ARCH_INCLUDE := powerpc/include CFLAGS += -m64
tools/kvm/powerpc/kvm-cpu.c +34 -0
@@ -24,6 +24,7 @@#include <string.h> #include <errno.h> #include <stdio.h> +#include <assert.h> static int debug_fd;
@@ -177,6 +178,39 @@ bool kvm_cpu__handle_exit(struct kvm_cpu *vcpu)return ret; } +bool kvm_cpu__emulate_io (struct kvm_cpu *cpu,struct kvm_run *kvm_run) +{ +bool ret = false; +u64 phys_addr; + +/* We'll never get KVM_EXIT_IO, it's x86-specific. All IO is MM! :P +* So, look at our windows here & split addresses into I/O or MMIO. +*/ +assert (kvm_run->exit_reason ==KVM_EXIT_MMIO ); + + phys_addr = cpu->kvm_run->mmio.phys_addr; +if ((phys_addr >=SPAPR_PCI_IO_WIN_ADDR ) && + (phys_addr <SPAPR_PCI_IO_WIN_ADDR +SPAPR_PCI_IO_WIN_SIZE )) { + ret =kvm__emulate_io (cpu->kvm, phys_addr -SPAPR_PCI_IO_WIN_ADDR , + cpu->kvm_run->mmio.data, + cpu->kvm_run->mmio.is_write ? +KVM_EXIT_IO_OUT :KVM_EXIT_IO_IN , + cpu->kvm_run->mmio.len,1 ); + }else if ((phys_addr >=SPAPR_PCI_MEM_WIN_ADDR ) && + (phys_addr <SPAPR_PCI_MEM_WIN_ADDR +SPAPR_PCI_MEM_WIN_SIZE )) { + ret =kvm__emulate_mmio (cpu->kvm, + cpu->kvm_run->mmio.phys_addr -SPAPR_PCI_MEM_WIN_ADDR , + cpu->kvm_run->mmio.data, + cpu->kvm_run->mmio.len, + cpu->kvm_run->mmio.is_write); + }else { +pr_warning ("MMIO %s unknown address %lx (size %d)!\n" , + cpu->kvm_run->mmio.is_write ?"write to" :"read from" , + phys_addr, cpu->kvm_run->mmio.len); + } +return ret; +} +#define CONDSTR_BIT (m, b) (((m) & MSR_##b) ? #b" " : "")void kvm_cpu__show_registers (struct kvm_cpu *vcpu)
PATCH 8/8 kvm tools: Make virtio-pci's ioeventfd__add_event() fall back gracefully if ioeventfds unavailable
In reply to a message not in the archivePPC KVM doesn't yet support ioeventfds, so don't bomb out/die. virtio-pci is able to function if it instead uses normal IO port notification.
--- tools/kvm/include/kvm/ioeventfd.h | 3 ++- tools/kvm/ioeventfd.c | 12 +++++++++--- tools/kvm/virtio/pci.c | 11 ++++++++++- 3 files changed, 21 insertions(+), 5 deletions(-)
tools/kvm/include/kvm/ioeventfd.h +2 -1
@@ -4,6 +4,7 @@#include <linux/types.h> #include <linux/list.h> #include <sys/eventfd.h> +#include <stdbool.h> struct kvm ;
@@ -21,7 +22,7 @@ struct ioevent {void ioeventfd__init (void );void ioeventfd__start (void ); -void ioeventfd__add_event (struct ioevent *ioevent); +bool ioeventfd__add_event (struct ioevent *ioevent);void ioeventfd__del_event (u64 addr,u64 datamatch);#endif
tools/kvm/ioeventfd.c +9 -3
@@ -26,7 +26,7 @@ void ioeventfd__init(void)die ("Failed creating epoll fd" ); } -void ioeventfd__add_event (struct ioevent *ioevent) +bool ioeventfd__add_event (struct ioevent *ioevent) {struct kvm_ioeventfd kvm_ioevent;struct epoll_event epoll_event;
@@ -48,8 +48,13 @@ void ioeventfd__add_event(struct ioevent *ioevent) .flags = KVM_IOEVENTFD_FLAG_PIO | KVM_IOEVENTFD_FLAG_DATAMATCH, }; -if (ioctl (ioevent->fn_kvm->vm_fd,KVM_IOEVENTFD , &kvm_ioevent) !=0 ) -die ("Failed creating new ioeventfd" ); +if (ioctl (ioevent->fn_kvm->vm_fd,KVM_IOEVENTFD , &kvm_ioevent) !=0 ) { +/* Not all KVM implementations may support KVM_IOEVENTFD, +* so be graceful. +*/ +free (new_ioevent); +return false; + } epoll_event = (struct epoll_event ) { .events =EPOLLIN ,
@@ -60,6 +65,7 @@ void ioeventfd__add_event(struct ioevent *ioevent)die ("Failed assigning new event to the epoll fd" );list_add_tail (&new_ioevent->list, &used_ioevents); +return true; }void ioeventfd__del_event (u64 addr,u64 datamatch)
tools/kvm/virtio/pci.c +10 -1
@@ -50,7 +50,16 @@ static int virtio_pci__init_ioeventfd(struct kvm *kvm, struct virtio_trans *vtra .fd = eventfd(0, 0), }; -ioeventfd__add_event (&ioevent); +if (!ioeventfd__add_event (&ioevent)) { +#ifndef CONFIG_PPC +/* PPC64 doesn't have kvm ioevents yet, so we expect this to +* fail -- don't need to be verbose about it! For virtio-pci, +* this is fine. It catches the IO accesses anyway, so +* still works (but slower). +*/ +pr_warning ("Failed creating new ioeventfd" ); +#endif + }if (vtrans->virtio_ops->notify_vq_eventfd) vtrans->virtio_ops->notify_vq_eventfd (kvm, vpci->dev, vq, ioevent.fd);