* [PATCH 01/15] KVM: PPC: Ensure split mode works
[not found] ` <1268071402-27112-1-git-send-email-agraf-l3A5Bk7waGM@public.gmane.org>
@ 2010-03-08 18:03 ` Alexander Graf
2010-03-08 18:03 ` [PATCH 03/15] KVM: PPC: Make DSISR 32 bits wide Alexander Graf
` (7 subsequent siblings)
8 siblings, 0 replies; 30+ messages in thread
From: Alexander Graf @ 2010-03-08 18:03 UTC (permalink / raw)
To: kvm-ppc-u79uwXL29TY76Z2rM5mHXA; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA
On PowerPC we can go into MMU Split Mode. That means that either
data relocation is on but instruction relocation is off or vice
versa.
That mode didn't work properly, as we weren't always flushing
entries when going into a new split mode, potentially mapping
different code or data that we're supposed to.
Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
arch/powerpc/include/asm/kvm_book3s.h | 9 +++---
arch/powerpc/kvm/book3s.c | 46 +++++++++++++++++---------------
2 files changed, 29 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index e6ea974..14d0262 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -99,10 +99,11 @@ struct kvmppc_vcpu_book3s {
#define CONTEXT_GUEST 1
#define CONTEXT_GUEST_END 2
-#define VSID_REAL 0xfffffffffff00000
-#define VSID_REAL_DR 0xffffffffffe00000
-#define VSID_REAL_IR 0xffffffffffd00000
-#define VSID_BAT 0xffffffffffc00000
+#define VSID_REAL_DR 0x7ffffffffff00000
+#define VSID_REAL_IR 0x7fffffffffe00000
+#define VSID_SPLIT_MASK 0x7fffffffffe00000
+#define VSID_REAL 0x7fffffffffc00000
+#define VSID_BAT 0x7fffffffffb00000
#define VSID_PR 0x8000000000000000
extern void kvmppc_mmu_pte_flush(struct kvm_vcpu *vcpu, u64 ea, u64 ea_mask);
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 94c229d..c2ffb91 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -133,6 +133,14 @@ void kvmppc_set_msr(struct kvm_vcpu *vcpu, u64 msr)
if (((vcpu->arch.msr & (MSR_IR|MSR_DR)) != (old_msr & (MSR_IR|MSR_DR))) ||
(vcpu->arch.msr & MSR_PR) != (old_msr & MSR_PR)) {
+ bool dr = (vcpu->arch.msr & MSR_DR) ? true : false;
+ bool ir = (vcpu->arch.msr & MSR_IR) ? true : false;
+
+ /* Flush split mode PTEs */
+ if (dr != ir)
+ kvmppc_mmu_pte_vflush(vcpu, VSID_SPLIT_MASK,
+ VSID_SPLIT_MASK);
+
kvmppc_mmu_flush_segments(vcpu);
kvmppc_mmu_map_segment(vcpu, vcpu->arch.pc);
}
@@ -395,15 +403,7 @@ static int kvmppc_xlate(struct kvm_vcpu *vcpu, ulong eaddr, bool data,
} else {
pte->eaddr = eaddr;
pte->raddr = eaddr & 0xffffffff;
- pte->vpage = eaddr >> 12;
- switch (vcpu->arch.msr & (MSR_DR|MSR_IR)) {
- case 0:
- pte->vpage |= VSID_REAL;
- case MSR_DR:
- pte->vpage |= VSID_REAL_DR;
- case MSR_IR:
- pte->vpage |= VSID_REAL_IR;
- }
+ pte->vpage = VSID_REAL | eaddr >> 12;
pte->may_read = true;
pte->may_write = true;
pte->may_execute = true;
@@ -512,12 +512,10 @@ int kvmppc_handle_pagefault(struct kvm_run *run, struct kvm_vcpu *vcpu,
int page_found = 0;
struct kvmppc_pte pte;
bool is_mmio = false;
+ bool dr = (vcpu->arch.msr & MSR_DR) ? true : false;
+ bool ir = (vcpu->arch.msr & MSR_IR) ? true : false;
- if ( vec == BOOK3S_INTERRUPT_DATA_STORAGE ) {
- relocated = (vcpu->arch.msr & MSR_DR);
- } else {
- relocated = (vcpu->arch.msr & MSR_IR);
- }
+ relocated = data ? dr : ir;
/* Resolve real address if translation turned on */
if (relocated) {
@@ -529,14 +527,18 @@ int kvmppc_handle_pagefault(struct kvm_run *run, struct kvm_vcpu *vcpu,
pte.raddr = eaddr & 0xffffffff;
pte.eaddr = eaddr;
pte.vpage = eaddr >> 12;
- switch (vcpu->arch.msr & (MSR_DR|MSR_IR)) {
- case 0:
- pte.vpage |= VSID_REAL;
- case MSR_DR:
- pte.vpage |= VSID_REAL_DR;
- case MSR_IR:
- pte.vpage |= VSID_REAL_IR;
- }
+ }
+
+ switch (vcpu->arch.msr & (MSR_DR|MSR_IR)) {
+ case 0:
+ pte.vpage |= VSID_REAL;
+ break;
+ case MSR_DR:
+ pte.vpage |= VSID_REAL_DR;
+ break;
+ case MSR_IR:
+ pte.vpage |= VSID_REAL_IR;
+ break;
}
if (vcpu->arch.mmu.is_dcbz32(vcpu) &&
--
1.6.0.2
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 03/15] KVM: PPC: Make DSISR 32 bits wide
[not found] ` <1268071402-27112-1-git-send-email-agraf-l3A5Bk7waGM@public.gmane.org>
2010-03-08 18:03 ` [PATCH 01/15] KVM: PPC: Ensure split mode works Alexander Graf
@ 2010-03-08 18:03 ` Alexander Graf
2010-03-08 18:03 ` [PATCH 05/15] KVM: PPC: Split instruction reading out Alexander Graf
` (6 subsequent siblings)
8 siblings, 0 replies; 30+ messages in thread
From: Alexander Graf @ 2010-03-08 18:03 UTC (permalink / raw)
To: kvm-ppc-u79uwXL29TY76Z2rM5mHXA; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA
DSISR is only defined as 32 bits wide. So let's reflect that in the
structs too.
Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
arch/powerpc/include/asm/kvm_book3s.h | 2 +-
arch/powerpc/include/asm/kvm_host.h | 2 +-
arch/powerpc/kvm/book3s_64_interrupts.S | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index 14d0262..9f5a992 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -84,8 +84,8 @@ struct kvmppc_vcpu_book3s {
u64 hid[6];
u64 gqr[8];
int slb_nr;
+ u32 dsisr;
u64 sdr1;
- u64 dsisr;
u64 hior;
u64 msr_mask;
u64 vsid_first;
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 119deb4..0ebda67 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -260,7 +260,7 @@ struct kvm_vcpu_arch {
u32 last_inst;
#ifdef CONFIG_PPC64
- ulong fault_dsisr;
+ u32 fault_dsisr;
#endif
ulong fault_dear;
ulong fault_esr;
diff --git a/arch/powerpc/kvm/book3s_64_interrupts.S b/arch/powerpc/kvm/book3s_64_interrupts.S
index c1584d0..faca876 100644
--- a/arch/powerpc/kvm/book3s_64_interrupts.S
+++ b/arch/powerpc/kvm/book3s_64_interrupts.S
@@ -171,7 +171,7 @@ kvmppc_handler_highmem:
std r3, VCPU_PC(r7)
std r4, VCPU_SHADOW_SRR1(r7)
std r5, VCPU_FAULT_DEAR(r7)
- std r6, VCPU_FAULT_DSISR(r7)
+ stw r6, VCPU_FAULT_DSISR(r7)
ld r5, VCPU_HFLAGS(r7)
rldicl. r5, r5, 0, 63 /* CR = ((r5 & 1) == 0) */
--
1.6.0.2
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 05/15] KVM: PPC: Split instruction reading out
[not found] ` <1268071402-27112-1-git-send-email-agraf-l3A5Bk7waGM@public.gmane.org>
2010-03-08 18:03 ` [PATCH 01/15] KVM: PPC: Ensure split mode works Alexander Graf
2010-03-08 18:03 ` [PATCH 03/15] KVM: PPC: Make DSISR 32 bits wide Alexander Graf
@ 2010-03-08 18:03 ` Alexander Graf
2010-03-08 18:03 ` [PATCH 07/15] KVM: PPC: Load VCPU for register fetching Alexander Graf
` (5 subsequent siblings)
8 siblings, 0 replies; 30+ messages in thread
From: Alexander Graf @ 2010-03-08 18:03 UTC (permalink / raw)
To: kvm-ppc-u79uwXL29TY76Z2rM5mHXA; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA
The current check_ext function reads the instruction and then does
the checking. Let's split the reading out so we can reuse it for
different functions.
Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
arch/powerpc/kvm/book3s.c | 24 ++++++++++++++++--------
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 9e0bc47..400ae0a 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -650,26 +650,34 @@ void kvmppc_giveup_ext(struct kvm_vcpu *vcpu, ulong msr)
kvmppc_recalc_shadow_msr(vcpu);
}
-static int kvmppc_check_ext(struct kvm_vcpu *vcpu, unsigned int exit_nr)
+static int kvmppc_read_inst(struct kvm_vcpu *vcpu)
{
ulong srr0 = vcpu->arch.pc;
int ret;
- /* Need to do paired single emulation? */
- if (!(vcpu->arch.hflags & BOOK3S_HFLAG_PAIRED_SINGLE))
- return EMULATE_DONE;
-
- /* Read out the instruction */
ret = kvmppc_ld(vcpu, &srr0, sizeof(u32), &vcpu->arch.last_inst, false);
if (ret == -ENOENT) {
vcpu->arch.msr = kvmppc_set_field(vcpu->arch.msr, 33, 33, 1);
vcpu->arch.msr = kvmppc_set_field(vcpu->arch.msr, 34, 36, 0);
vcpu->arch.msr = kvmppc_set_field(vcpu->arch.msr, 42, 47, 0);
kvmppc_book3s_queue_irqprio(vcpu, BOOK3S_INTERRUPT_INST_STORAGE);
- } else if(ret == EMULATE_DONE) {
+ return EMULATE_AGAIN;
+ }
+
+ return EMULATE_DONE;
+}
+
+static int kvmppc_check_ext(struct kvm_vcpu *vcpu, unsigned int exit_nr)
+{
+
+ /* Need to do paired single emulation? */
+ if (!(vcpu->arch.hflags & BOOK3S_HFLAG_PAIRED_SINGLE))
+ return EMULATE_DONE;
+
+ /* Read out the instruction */
+ if (kvmppc_read_inst(vcpu) == EMULATE_DONE)
/* Need to emulate */
return EMULATE_FAIL;
- }
return EMULATE_AGAIN;
}
--
1.6.0.2
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 07/15] KVM: PPC: Load VCPU for register fetching
[not found] ` <1268071402-27112-1-git-send-email-agraf-l3A5Bk7waGM@public.gmane.org>
` (2 preceding siblings ...)
2010-03-08 18:03 ` [PATCH 05/15] KVM: PPC: Split instruction reading out Alexander Graf
@ 2010-03-08 18:03 ` Alexander Graf
2010-03-08 18:03 ` [PATCH 08/15] KVM: PPC: Implement mfsr emulation Alexander Graf
` (4 subsequent siblings)
8 siblings, 0 replies; 30+ messages in thread
From: Alexander Graf @ 2010-03-08 18:03 UTC (permalink / raw)
To: kvm-ppc-u79uwXL29TY76Z2rM5mHXA; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA
When trying to read or store vcpu register data, we should also make
sure the vcpu is actually loaded, so we're 100% sure we get the correct
values.
Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
arch/powerpc/kvm/book3s.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 029e1be..585dc91 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -955,6 +955,8 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
{
int i;
+ vcpu_load(vcpu);
+
regs->pc = vcpu->arch.pc;
regs->cr = kvmppc_get_cr(vcpu);
regs->ctr = vcpu->arch.ctr;
@@ -975,6 +977,8 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
for (i = 0; i < ARRAY_SIZE(regs->gpr); i++)
regs->gpr[i] = kvmppc_get_gpr(vcpu, i);
+ vcpu_put(vcpu);
+
return 0;
}
@@ -982,6 +986,8 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
{
int i;
+ vcpu_load(vcpu);
+
vcpu->arch.pc = regs->pc;
kvmppc_set_cr(vcpu, regs->cr);
vcpu->arch.ctr = regs->ctr;
@@ -1001,6 +1007,8 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
for (i = 0; i < ARRAY_SIZE(regs->gpr); i++)
kvmppc_set_gpr(vcpu, i, regs->gpr[i]);
+ vcpu_put(vcpu);
+
return 0;
}
--
1.6.0.2
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 08/15] KVM: PPC: Implement mfsr emulation
[not found] ` <1268071402-27112-1-git-send-email-agraf-l3A5Bk7waGM@public.gmane.org>
` (3 preceding siblings ...)
2010-03-08 18:03 ` [PATCH 07/15] KVM: PPC: Load VCPU for register fetching Alexander Graf
@ 2010-03-08 18:03 ` Alexander Graf
2010-03-08 18:03 ` [PATCH 12/15] KVM: PPC: Implement alignment interrupt Alexander Graf
` (3 subsequent siblings)
8 siblings, 0 replies; 30+ messages in thread
From: Alexander Graf @ 2010-03-08 18:03 UTC (permalink / raw)
To: kvm-ppc-u79uwXL29TY76Z2rM5mHXA; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA
We emulate the mfsrin instruction already, that passes the SR number
in a register value. But we lacked support for mfsr that encoded the
SR number in the opcode.
So let's implement it.
Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
arch/powerpc/kvm/book3s_64_emulate.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_emulate.c b/arch/powerpc/kvm/book3s_64_emulate.c
index c989214..8d7a78d 100644
--- a/arch/powerpc/kvm/book3s_64_emulate.c
+++ b/arch/powerpc/kvm/book3s_64_emulate.c
@@ -35,6 +35,7 @@
#define OP_31_XOP_SLBMTE 402
#define OP_31_XOP_SLBIE 434
#define OP_31_XOP_SLBIA 498
+#define OP_31_XOP_MFSR 595
#define OP_31_XOP_MFSRIN 659
#define OP_31_XOP_SLBMFEV 851
#define OP_31_XOP_EIOIO 854
@@ -90,6 +91,18 @@ int kvmppc_core_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
case OP_31_XOP_MTMSR:
kvmppc_set_msr(vcpu, kvmppc_get_gpr(vcpu, get_rs(inst)));
break;
+ case OP_31_XOP_MFSR:
+ {
+ int srnum;
+
+ srnum = kvmppc_get_field(inst, 12 + 32, 15 + 32);
+ if (vcpu->arch.mmu.mfsrin) {
+ u32 sr;
+ sr = vcpu->arch.mmu.mfsrin(vcpu, srnum);
+ kvmppc_set_gpr(vcpu, get_rt(inst), sr);
+ }
+ break;
+ }
case OP_31_XOP_MFSRIN:
{
int srnum;
--
1.6.0.2
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 12/15] KVM: PPC: Implement alignment interrupt
[not found] ` <1268071402-27112-1-git-send-email-agraf-l3A5Bk7waGM@public.gmane.org>
` (4 preceding siblings ...)
2010-03-08 18:03 ` [PATCH 08/15] KVM: PPC: Implement mfsr emulation Alexander Graf
@ 2010-03-08 18:03 ` Alexander Graf
2010-03-08 18:03 ` [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu Alexander Graf
` (2 subsequent siblings)
8 siblings, 0 replies; 30+ messages in thread
From: Alexander Graf @ 2010-03-08 18:03 UTC (permalink / raw)
To: kvm-ppc-u79uwXL29TY76Z2rM5mHXA; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA
Mac OS X has some applications - namely the Finder - that require alignment
interrupts to work properly. So we need to implement them.
But the spec for 970 and 750 also looks different. While 750 requires the
DSISR fields to reflect some instruction bits, the 970 declares this as an
optional feature. So we need to reconstruct DSISR manually.
Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
arch/powerpc/include/asm/kvm_book3s.h | 1 +
arch/powerpc/kvm/book3s.c | 9 +++++++
arch/powerpc/kvm/book3s_64_emulate.c | 40 +++++++++++++++++++++++++++++++++
3 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index b47b2f5..1a169f3 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -131,6 +131,7 @@ extern void kvmppc_rmcall(ulong srr0, ulong srr1);
extern void kvmppc_load_up_fpu(void);
extern void kvmppc_load_up_altivec(void);
extern void kvmppc_load_up_vsx(void);
+extern u32 kvmppc_alignment_dsisr(struct kvm_vcpu *vcpu, unsigned int inst);
static inline struct kvmppc_vcpu_book3s *to_book3s(struct kvm_vcpu *vcpu)
{
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 585dc91..6b8b5ed 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -905,6 +905,15 @@ program_interrupt:
}
break;
}
+ case BOOK3S_INTERRUPT_ALIGNMENT:
+ vcpu->arch.dear = vcpu->arch.fault_dear;
+ if (kvmppc_read_inst(vcpu) == EMULATE_DONE) {
+ to_book3s(vcpu)->dsisr = kvmppc_alignment_dsisr(vcpu,
+ vcpu->arch.last_inst);
+ kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
+ }
+ r = RESUME_GUEST;
+ break;
case BOOK3S_INTERRUPT_MACHINE_CHECK:
case BOOK3S_INTERRUPT_TRACE:
kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
diff --git a/arch/powerpc/kvm/book3s_64_emulate.c b/arch/powerpc/kvm/book3s_64_emulate.c
index 39d5003..c401dd4 100644
--- a/arch/powerpc/kvm/book3s_64_emulate.c
+++ b/arch/powerpc/kvm/book3s_64_emulate.c
@@ -44,6 +44,8 @@
/* DCBZ is actually 1014, but we patch it to 1010 so we get a trap */
#define OP_31_XOP_DCBZ 1010
+#define OP_LFS 48
+
#define SPRN_GQR0 912
#define SPRN_GQR1 913
#define SPRN_GQR2 914
@@ -474,3 +476,41 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt)
return emulated;
}
+u32 kvmppc_alignment_dsisr(struct kvm_vcpu *vcpu, unsigned int inst)
+{
+ u32 dsisr = 0;
+
+ /*
+ * This is what the spec says about DSISR bits (not mentioned = 0):
+ *
+ * 12:13 [DS] Set to bits 30:31
+ * 15:16 [X] Set to bits 29:30
+ * 17 [X] Set to bit 25
+ * [D/DS] Set to bit 5
+ * 18:21 [X] Set to bits 21:24
+ * [D/DS] Set to bits 1:4
+ * 22:26 Set to bits 6:10 (RT/RS/FRT/FRS)
+ * 27:31 Set to bits 11:15 (RA)
+ */
+
+ switch (get_op(inst)) {
+ /* D-form */
+ case OP_LFS:
+ dsisr |= (inst >> 12) & 0x4000; /* bit 17 */
+ dsisr |= (inst >> 17) & 0x3c00; /* bits 18:21 */
+ break;
+ /* X-form */
+ case 31:
+ dsisr |= (inst << 14) & 0x18000; /* bits 15:16 */
+ dsisr |= (inst << 8) & 0x04000; /* bit 17 */
+ dsisr |= (inst << 3) & 0x03c00; /* bits 18:21 */
+ break;
+ default:
+ printk(KERN_INFO "KVM: Unaligned instruction 0x%x\n", inst);
+ break;
+ }
+
+ dsisr |= (inst >> 16) & 0x03ff; /* bits 22:31 */
+
+ return dsisr;
+}
--
1.6.0.2
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu
[not found] ` <1268071402-27112-1-git-send-email-agraf-l3A5Bk7waGM@public.gmane.org>
` (5 preceding siblings ...)
2010-03-08 18:03 ` [PATCH 12/15] KVM: PPC: Implement alignment interrupt Alexander Graf
@ 2010-03-08 18:03 ` Alexander Graf
2010-03-09 12:56 ` Avi Kivity
2010-03-08 18:03 ` [PATCH 14/15] KVM: PPC: Add OSI hypercall interface Alexander Graf
2010-03-08 18:03 ` [PATCH 15/15] KVM: PPC: Make build work without CONFIG_VSX/ALTIVEC Alexander Graf
8 siblings, 1 reply; 30+ messages in thread
From: Alexander Graf @ 2010-03-08 18:03 UTC (permalink / raw)
To: kvm-ppc-u79uwXL29TY76Z2rM5mHXA; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA
Some times we don't want all capabilities to be available to all
our vcpus. One example for that is the OSI interface, implemented
in the next patch.
In order to have a generic mechanism in how to enable capabilities
individually, this patch introduces a new ioctl that can be used
for this purpose. That way features we don't want in all guests or
userspace configurations can just not be enabled and we're good.
Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
v1 -> v2:
- Add flags to enable_cap
- Update documentation for kvm_enable_cap
---
Documentation/kvm/api.txt | 15 +++++++++++++++
arch/powerpc/kvm/powerpc.c | 26 ++++++++++++++++++++++++++
include/linux/kvm.h | 11 +++++++++++
3 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index d170cb4..6a19ab6 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -749,6 +749,21 @@ Writes debug registers into the vcpu.
See KVM_GET_DEBUGREGS for the data structure. The flags field is unused
yet and must be cleared on entry.
+4.34 KVM_ENABLE_CAP
+
+Capability: basic
+Architectures: all
+Type: vcpu ioctl
+Parameters: struct kvm_enable_cap (in)
+Returns: 0 on success; -1 on error
+
+Not all extensions are enabled by default. Using this ioctl the application
+can enable an extension, making it available to the guest.
+
+On systems that do not support this ioctl, it always fails. On systems that
+do support it, it only works for extensions that are supported for enablement.
+As of writing this the only enablement enabled extenion is KVM_CAP_PPC_OSI.
+
5. The kvm_run structure
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index a28a512..8bd8204 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -462,6 +462,23 @@ int kvm_vcpu_ioctl_interrupt(struct kvm_vcpu *vcpu, struct kvm_interrupt *irq)
return 0;
}
+static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
+ struct kvm_enable_cap *cap)
+{
+ int r;
+
+ if (cap->flags)
+ return -EINVAL;
+
+ switch (cap->cap) {
+ default:
+ r = -EINVAL;
+ break;
+ }
+
+ return r;
+}
+
int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
struct kvm_mp_state *mp_state)
{
@@ -490,6 +507,15 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
r = kvm_vcpu_ioctl_interrupt(vcpu, &irq);
break;
}
+ case KVM_ENABLE_CAP:
+ {
+ struct kvm_enable_cap cap;
+ r = -EFAULT;
+ if (copy_from_user(&cap, argp, sizeof(cap)))
+ goto out;
+ r = kvm_vcpu_ioctl_enable_cap(vcpu, &cap);
+ break;
+ }
default:
r = -EINVAL;
}
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index ce28767..a18ac92 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -400,6 +400,15 @@ struct kvm_ioeventfd {
__u8 pad[36];
};
+/* for KVM_ENABLE_CAP */
+struct kvm_enable_cap {
+ /* in */
+ __u32 cap;
+ __u32 flags;
+ __u64 args[4];
+ __u8 pad[64];
+};
+
#define KVMIO 0xAE
/*
@@ -696,6 +705,8 @@ struct kvm_clock_data {
/* Available with KVM_CAP_DEBUGREGS */
#define KVM_GET_DEBUGREGS _IOR(KVMIO, 0xa1, struct kvm_debugregs)
#define KVM_SET_DEBUGREGS _IOW(KVMIO, 0xa2, struct kvm_debugregs)
+/* No need for CAP, because then it just always fails */
+#define KVM_ENABLE_CAP _IOW(KVMIO, 0xa3, struct kvm_enable_cap)
#define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0)
--
1.6.0.2
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu
2010-03-08 18:03 ` [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu Alexander Graf
@ 2010-03-09 12:56 ` Avi Kivity
2010-03-09 13:01 ` Alexander Graf
0 siblings, 1 reply; 30+ messages in thread
From: Avi Kivity @ 2010-03-09 12:56 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-ppc, kvm
On 03/08/2010 08:03 PM, Alexander Graf wrote:
> Some times we don't want all capabilities to be available to all
> our vcpus. One example for that is the OSI interface, implemented
> in the next patch.
>
> In order to have a generic mechanism in how to enable capabilities
> individually, this patch introduces a new ioctl that can be used
> for this purpose. That way features we don't want in all guests or
> userspace configurations can just not be enabled and we're good.
>
>
> diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
> index d170cb4..6a19ab6 100644
> --- a/Documentation/kvm/api.txt
> +++ b/Documentation/kvm/api.txt
> @@ -749,6 +749,21 @@ Writes debug registers into the vcpu.
> See KVM_GET_DEBUGREGS for the data structure. The flags field is unused
> yet and must be cleared on entry.
>
> +4.34 KVM_ENABLE_CAP
> +
> +Capability: basic
>
Capability: basic means that the feature was present in 2.6.22.
Otherwise you need to specify the KVM_CAP_ that presents this feature.
> +Architectures: all
>
>
But it's implemented for ppc only (other arches will get ENOTTY).
> +Not all extensions are enabled by default. Using this ioctl the application
> +can enable an extension, making it available to the guest.
> +
> +On systems that do not support this ioctl, it always fails. On systems that
> +do support it, it only works for extensions that are supported for enablement.
> +As of writing this the only enablement enabled extenion is KVM_CAP_PPC_OSI.
>
That needs to be documented. It also needs to be discoverable
separately - we can have a kernel with KVM_ENABLE_CAP but without
KVM_CAP_PPC_OSI.
btw, KVM_CAP_PPC_OSI conflicts with the KVM_CAP_ namespace. Please
choose another namespace.
Need to document the structure fields.
>
> /*
> @@ -696,6 +705,8 @@ struct kvm_clock_data {
> /* Available with KVM_CAP_DEBUGREGS */
> #define KVM_GET_DEBUGREGS _IOR(KVMIO, 0xa1, struct kvm_debugregs)
> #define KVM_SET_DEBUGREGS _IOW(KVMIO, 0xa2, struct kvm_debugregs)
> +/* No need for CAP, because then it just always fails */
> +#define KVM_ENABLE_CAP _IOW(KVMIO, 0xa3, struct kvm_enable_cap)
>
The CAPs are needed so you can discover what you have without running guests.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu
2010-03-09 12:56 ` Avi Kivity
@ 2010-03-09 13:01 ` Alexander Graf
2010-03-09 13:09 ` Avi Kivity
0 siblings, 1 reply; 30+ messages in thread
From: Alexander Graf @ 2010-03-09 13:01 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm-ppc, kvm
On 09.03.2010, at 13:56, Avi Kivity wrote:
> On 03/08/2010 08:03 PM, Alexander Graf wrote:
>> Some times we don't want all capabilities to be available to all
>> our vcpus. One example for that is the OSI interface, implemented
>> in the next patch.
>>
>> In order to have a generic mechanism in how to enable capabilities
>> individually, this patch introduces a new ioctl that can be used
>> for this purpose. That way features we don't want in all guests or
>> userspace configurations can just not be enabled and we're good.
>>
>>
>> diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
>> index d170cb4..6a19ab6 100644
>> --- a/Documentation/kvm/api.txt
>> +++ b/Documentation/kvm/api.txt
>> @@ -749,6 +749,21 @@ Writes debug registers into the vcpu.
>> See KVM_GET_DEBUGREGS for the data structure. The flags field is unused
>> yet and must be cleared on entry.
>>
>> +4.34 KVM_ENABLE_CAP
>> +
>> +Capability: basic
>>
>
> Capability: basic means that the feature was present in 2.6.22. Otherwise you need to specify the KVM_CAP_ that presents this feature.
>
>> +Architectures: all
>>
>>
>
> But it's implemented for ppc only (other arches will get ENOTTY).
That was the whole idea behind it. if it fails it fails. Nothing we can do about it. If it succeeds - great.
>
>> +Not all extensions are enabled by default. Using this ioctl the application
>> +can enable an extension, making it available to the guest.
>> +
>> +On systems that do not support this ioctl, it always fails. On systems that
>> +do support it, it only works for extensions that are supported for enablement.
>> +As of writing this the only enablement enabled extenion is KVM_CAP_PPC_OSI.
>>
>
> That needs to be documented. It also needs to be discoverable separately - we can have a kernel with KVM_ENABLE_CAP but without KVM_CAP_PPC_OSI.
>
> btw, KVM_CAP_PPC_OSI conflicts with the KVM_CAP_ namespace. Please choose another namespace.
Well I figured it'd be slick to have capabilities get enabled or disabled. That's the whole idea behind making it generic. If I wanted a specific interface I'd go in and create an ioctl ENABLE_OSI_INTERFACE.
But this way the detection if a capability exists can be done using the existing CAP detection. It can then be enabled using ENABLE_CAP.
> Need to document the structure fields.
>
>>
>> /*
>> @@ -696,6 +705,8 @@ struct kvm_clock_data {
>> /* Available with KVM_CAP_DEBUGREGS */
>> #define KVM_GET_DEBUGREGS _IOR(KVMIO, 0xa1, struct kvm_debugregs)
>> #define KVM_SET_DEBUGREGS _IOW(KVMIO, 0xa2, struct kvm_debugregs)
>> +/* No need for CAP, because then it just always fails */
>> +#define KVM_ENABLE_CAP _IOW(KVMIO, 0xa3, struct kvm_enable_cap)
>>
> The CAPs are needed so you can discover what you have without running guests.
The whole point of this extension was to make CAPs not always enabled, but make them possibly enable on demand.
Alex
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu
2010-03-09 13:01 ` Alexander Graf
@ 2010-03-09 13:09 ` Avi Kivity
0 siblings, 0 replies; 30+ messages in thread
From: Avi Kivity @ 2010-03-09 13:09 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-ppc, kvm
On 03/09/2010 03:01 PM, Alexander Graf wrote:
> On 09.03.2010, at 13:56, Avi Kivity wrote:
>
>
>> On 03/08/2010 08:03 PM, Alexander Graf wrote:
>>
>>> Some times we don't want all capabilities to be available to all
>>> our vcpus. One example for that is the OSI interface, implemented
>>> in the next patch.
>>>
>>> In order to have a generic mechanism in how to enable capabilities
>>> individually, this patch introduces a new ioctl that can be used
>>> for this purpose. That way features we don't want in all guests or
>>> userspace configurations can just not be enabled and we're good.
>>>
>>>
>>> diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
>>> index d170cb4..6a19ab6 100644
>>> --- a/Documentation/kvm/api.txt
>>> +++ b/Documentation/kvm/api.txt
>>> @@ -749,6 +749,21 @@ Writes debug registers into the vcpu.
>>> See KVM_GET_DEBUGREGS for the data structure. The flags field is unused
>>> yet and must be cleared on entry.
>>>
>>> +4.34 KVM_ENABLE_CAP
>>> +
>>> +Capability: basic
>>>
>>>
>> Capability: basic means that the feature was present in 2.6.22. Otherwise you need to specify the KVM_CAP_ that presents this feature.
>>
>>
>>> +Architectures: all
>>>
>>>
>>>
>> But it's implemented for ppc only (other arches will get ENOTTY).
>>
> That was the whole idea behind it. if it fails it fails. Nothing we can do about it. If it succeeds - great.
>
If KVM_CAP_ENABLE_CAP is present, it means the KVM_ENABLE_CAP ioctl will
not return ENOTTY (it may return EINVAL if wrong values are present).
ENOTTY means not implemented. 'Architectures: all' means implemented.
>>> +Not all extensions are enabled by default. Using this ioctl the application
>>> +can enable an extension, making it available to the guest.
>>> +
>>> +On systems that do not support this ioctl, it always fails. On systems that
>>> +do support it, it only works for extensions that are supported for enablement.
>>> +As of writing this the only enablement enabled extenion is KVM_CAP_PPC_OSI.
>>>
>>>
>> That needs to be documented. It also needs to be discoverable separately - we can have a kernel with KVM_ENABLE_CAP but without KVM_CAP_PPC_OSI.
>>
>> btw, KVM_CAP_PPC_OSI conflicts with the KVM_CAP_ namespace. Please choose another namespace.
>>
> Well I figured it'd be slick to have capabilities get enabled or disabled. That's the whole idea behind making it generic. If I wanted a specific interface I'd go in and create an ioctl ENABLE_OSI_INTERFACE.
>
Ah, I see. Well, that makes sense. Please document it.
> But this way the detection if a capability exists can be done using the existing CAP detection. It can then be enabled using ENABLE_CAP.
>
Okay, I agree.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 14/15] KVM: PPC: Add OSI hypercall interface
[not found] ` <1268071402-27112-1-git-send-email-agraf-l3A5Bk7waGM@public.gmane.org>
` (6 preceding siblings ...)
2010-03-08 18:03 ` [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu Alexander Graf
@ 2010-03-08 18:03 ` Alexander Graf
2010-03-09 13:00 ` Avi Kivity
2010-03-08 18:03 ` [PATCH 15/15] KVM: PPC: Make build work without CONFIG_VSX/ALTIVEC Alexander Graf
8 siblings, 1 reply; 30+ messages in thread
From: Alexander Graf @ 2010-03-08 18:03 UTC (permalink / raw)
To: kvm-ppc-u79uwXL29TY76Z2rM5mHXA; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA
MOL uses its own hypercall interface to call back into userspace when
the guest wants to do something.
So let's implement that as an exit reason, specify it with a CAP and
only really use it when userspace wants us to.
The only user of it so far is MOL.
Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
v1 -> v2:
- Add documentation for OSI exit struct
---
Documentation/kvm/api.txt | 13 +++++++++++++
arch/powerpc/include/asm/kvm_book3s.h | 5 +++++
arch/powerpc/include/asm/kvm_host.h | 2 ++
arch/powerpc/kvm/book3s.c | 24 ++++++++++++++++++------
arch/powerpc/kvm/powerpc.c | 12 ++++++++++++
include/linux/kvm.h | 6 ++++++
6 files changed, 56 insertions(+), 6 deletions(-)
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index 6a19ab6..b2129e8 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -932,6 +932,19 @@ s390 specific.
powerpc specific.
+ /* KVM_EXIT_OSI */
+ struct {
+ __u64 gprs[32];
+ } osi;
+
+MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
+hypercalls and exit with this exit struct that contains all the guest gprs.
+
+If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
+Userspace can now handle the hypercall and when it's done modify the gprs as
+necessary. Upon guest entry all guest GPRs will then be replaced by the values
+in this struct.
+
/* Fix the size of the union. */
char padding[256];
};
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index 1a169f3..54929cd 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -147,6 +147,11 @@ static inline ulong dsisr(void)
extern void kvm_return_point(void);
+/* Magic register values loaded into r3 and r4 before the 'sc' assembly
+ * instruction for the OSI hypercalls */
+#define OSI_SC_MAGIC_R3 0x113724FA
+#define OSI_SC_MAGIC_R4 0x77810F9B
+
#define INS_DCBZ 0x7c0007ec
#endif /* __ASM_KVM_BOOK3S_H__ */
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 0ebda67..486f1ca 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -273,6 +273,8 @@ struct kvm_vcpu_arch {
u8 mmio_sign_extend;
u8 dcr_needed;
u8 dcr_is_write;
+ u8 osi_needed;
+ u8 osi_enabled;
u32 cpr0_cfgaddr; /* holds the last set cpr0_cfgaddr */
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 6b8b5ed..e752a59 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -871,12 +871,24 @@ program_interrupt:
break;
}
case BOOK3S_INTERRUPT_SYSCALL:
-#ifdef EXIT_DEBUG
- printk(KERN_INFO "Syscall Nr %d\n", (int)kvmppc_get_gpr(vcpu, 0));
-#endif
- vcpu->stat.syscall_exits++;
- kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
- r = RESUME_GUEST;
+ // XXX make user settable
+ if (vcpu->arch.osi_enabled &&
+ (((u32)kvmppc_get_gpr(vcpu, 3)) == OSI_SC_MAGIC_R3) &&
+ (((u32)kvmppc_get_gpr(vcpu, 4)) == OSI_SC_MAGIC_R4)) {
+ u64 *gprs = run->osi.gprs;
+ int i;
+
+ run->exit_reason = KVM_EXIT_OSI;
+ for (i = 0; i < 32; i++)
+ gprs[i] = kvmppc_get_gpr(vcpu, i);
+ vcpu->arch.osi_needed = 1;
+ r = RESUME_HOST_NV;
+
+ } else {
+ vcpu->stat.syscall_exits++;
+ kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
+ r = RESUME_GUEST;
+ }
break;
case BOOK3S_INTERRUPT_FP_UNAVAIL:
case BOOK3S_INTERRUPT_ALTIVEC:
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 8bd8204..035bad4 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -148,6 +148,7 @@ int kvm_dev_ioctl_check_extension(long ext)
switch (ext) {
case KVM_CAP_PPC_SEGSTATE:
case KVM_CAP_PPC_PAIRED_SINGLES:
+ case KVM_CAP_PPC_OSI:
r = 1;
break;
case KVM_CAP_COALESCED_MMIO:
@@ -429,6 +430,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
if (!vcpu->arch.dcr_is_write)
kvmppc_complete_dcr_load(vcpu, run);
vcpu->arch.dcr_needed = 0;
+ } else if (vcpu->arch.osi_needed) {
+ u64 *gprs = run->osi.gprs;
+ int i;
+
+ for (i = 0; i < 32; i++)
+ kvmppc_set_gpr(vcpu, i, gprs[i]);
+ vcpu->arch.osi_needed = 0;
}
kvmppc_core_deliver_interrupts(vcpu);
@@ -471,6 +479,10 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
return -EINVAL;
switch (cap->cap) {
+ case KVM_CAP_PPC_OSI:
+ r = 0;
+ vcpu->arch.osi_enabled = true;
+ break;
default:
r = -EINVAL;
break;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index a18ac92..0307961 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -160,6 +160,7 @@ struct kvm_pit_config {
#define KVM_EXIT_DCR 15
#define KVM_EXIT_NMI 16
#define KVM_EXIT_INTERNAL_ERROR 17
+#define KVM_EXIT_OSI 18
/* For KVM_EXIT_INTERNAL_ERROR */
#define KVM_INTERNAL_ERROR_EMULATION 1
@@ -259,6 +260,10 @@ struct kvm_run {
__u32 ndata;
__u64 data[16];
} internal;
+ /* KVM_EXIT_OSI */
+ struct {
+ __u64 gprs[32];
+ } osi;
/* Fix the size of the union. */
char padding[256];
};
@@ -516,6 +521,7 @@ struct kvm_enable_cap {
#define KVM_CAP_DEBUGREGS 50
#endif
#define KVM_CAP_X86_ROBUST_SINGLESTEP 51
+#define KVM_CAP_PPC_OSI 52
#ifdef KVM_CAP_IRQ_ROUTING
--
1.6.0.2
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 14/15] KVM: PPC: Add OSI hypercall interface
2010-03-08 18:03 ` [PATCH 14/15] KVM: PPC: Add OSI hypercall interface Alexander Graf
@ 2010-03-09 13:00 ` Avi Kivity
2010-03-09 13:04 ` Alexander Graf
0 siblings, 1 reply; 30+ messages in thread
From: Avi Kivity @ 2010-03-09 13:00 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-ppc, kvm
On 03/08/2010 08:03 PM, Alexander Graf wrote:
> MOL uses its own hypercall interface to call back into userspace when
> the guest wants to do something.
>
> So let's implement that as an exit reason, specify it with a CAP and
> only really use it when userspace wants us to.
>
> The only user of it so far is MOL.
>
> Signed-off-by: Alexander Graf<agraf@suse.de>
>
> ---
>
> v1 -> v2:
>
> - Add documentation for OSI exit struct
> ---
> Documentation/kvm/api.txt | 13 +++++++++++++
> arch/powerpc/include/asm/kvm_book3s.h | 5 +++++
> arch/powerpc/include/asm/kvm_host.h | 2 ++
> arch/powerpc/kvm/book3s.c | 24 ++++++++++++++++++------
> arch/powerpc/kvm/powerpc.c | 12 ++++++++++++
> include/linux/kvm.h | 6 ++++++
> 6 files changed, 56 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
> index 6a19ab6..b2129e8 100644
> --- a/Documentation/kvm/api.txt
> +++ b/Documentation/kvm/api.txt
> @@ -932,6 +932,19 @@ s390 specific.
>
> powerpc specific.
>
> + /* KVM_EXIT_OSI */
> + struct {
> + __u64 gprs[32];
> + } osi;
> +
> +MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
> +hypercalls and exit with this exit struct that contains all the guest gprs.
> +
> +If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
> +Userspace can now handle the hypercall and when it's done modify the gprs as
> +necessary. Upon guest entry all guest GPRs will then be replaced by the values
> +in this struct.
> +
>
That's migration unsafe. There may not be next guest entry on this host.
Is using KVM_[GS]ET_REGS problematic for some reason?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 14/15] KVM: PPC: Add OSI hypercall interface
2010-03-09 13:00 ` Avi Kivity
@ 2010-03-09 13:04 ` Alexander Graf
2010-03-09 13:11 ` Avi Kivity
0 siblings, 1 reply; 30+ messages in thread
From: Alexander Graf @ 2010-03-09 13:04 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm-ppc, kvm
On 09.03.2010, at 14:00, Avi Kivity wrote:
> On 03/08/2010 08:03 PM, Alexander Graf wrote:
>> MOL uses its own hypercall interface to call back into userspace when
>> the guest wants to do something.
>>
>> So let's implement that as an exit reason, specify it with a CAP and
>> only really use it when userspace wants us to.
>>
>> The only user of it so far is MOL.
>>
>> Signed-off-by: Alexander Graf<agraf@suse.de>
>>
>> ---
>>
>> v1 -> v2:
>>
>> - Add documentation for OSI exit struct
>> ---
>> Documentation/kvm/api.txt | 13 +++++++++++++
>> arch/powerpc/include/asm/kvm_book3s.h | 5 +++++
>> arch/powerpc/include/asm/kvm_host.h | 2 ++
>> arch/powerpc/kvm/book3s.c | 24 ++++++++++++++++++------
>> arch/powerpc/kvm/powerpc.c | 12 ++++++++++++
>> include/linux/kvm.h | 6 ++++++
>> 6 files changed, 56 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
>> index 6a19ab6..b2129e8 100644
>> --- a/Documentation/kvm/api.txt
>> +++ b/Documentation/kvm/api.txt
>> @@ -932,6 +932,19 @@ s390 specific.
>>
>> powerpc specific.
>>
>> + /* KVM_EXIT_OSI */
>> + struct {
>> + __u64 gprs[32];
>> + } osi;
>> +
>> +MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
>> +hypercalls and exit with this exit struct that contains all the guest gprs.
>> +
>> +If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
>> +Userspace can now handle the hypercall and when it's done modify the gprs as
>> +necessary. Upon guest entry all guest GPRs will then be replaced by the values
>> +in this struct.
>> +
>>
>
> That's migration unsafe. There may not be next guest entry on this host.
It's as unsafe as MMIO then.
> Is using KVM_[GS]ET_REGS problematic for some reason?
It's two additional ioctls for no good reason. We know the interface, so we can model towards it.
Alex
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 14/15] KVM: PPC: Add OSI hypercall interface
2010-03-09 13:04 ` Alexander Graf
@ 2010-03-09 13:11 ` Avi Kivity
2010-03-09 13:12 ` Alexander Graf
0 siblings, 1 reply; 30+ messages in thread
From: Avi Kivity @ 2010-03-09 13:11 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-ppc, kvm
On 03/09/2010 03:04 PM, Alexander Graf wrote:
>
>>> + /* KVM_EXIT_OSI */
>>> + struct {
>>> + __u64 gprs[32];
>>> + } osi;
>>> +
>>> +MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
>>> +hypercalls and exit with this exit struct that contains all the guest gprs.
>>> +
>>> +If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
>>> +Userspace can now handle the hypercall and when it's done modify the gprs as
>>> +necessary. Upon guest entry all guest GPRs will then be replaced by the values
>>> +in this struct.
>>> +
>>>
>>>
>> That's migration unsafe. There may not be next guest entry on this host.
>>
> It's as unsafe as MMIO then.
>
>
From api.txt:
> NOTE: For KVM_EXIT_IO and KVM_EXIT_MMIO, the corresponding operations
> are complete (and guest state is consistent) only after userspace has
> re-entered the kernel with KVM_RUN. The kernel side will first finish
> incomplete operations and then check for pending signals. Userspace
> can re-enter the guest with an unmasked signal pending to complete
> pending operations.
>> Is using KVM_[GS]ET_REGS problematic for some reason?
>>
> It's two additional ioctls for no good reason. We know the interface, so we can model towards it.
>
But we need to be migration safe. If the interface is not heavily used,
let's not add complications.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 14/15] KVM: PPC: Add OSI hypercall interface
2010-03-09 13:11 ` Avi Kivity
@ 2010-03-09 13:12 ` Alexander Graf
[not found] ` <3D0D6963-FEC8-4A53-ACCE-570BEAF3721B-l3A5Bk7waGM@public.gmane.org>
0 siblings, 1 reply; 30+ messages in thread
From: Alexander Graf @ 2010-03-09 13:12 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm-ppc, kvm
On 09.03.2010, at 14:11, Avi Kivity wrote:
> On 03/09/2010 03:04 PM, Alexander Graf wrote:
>>
>>>> + /* KVM_EXIT_OSI */
>>>> + struct {
>>>> + __u64 gprs[32];
>>>> + } osi;
>>>> +
>>>> +MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
>>>> +hypercalls and exit with this exit struct that contains all the guest gprs.
>>>> +
>>>> +If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
>>>> +Userspace can now handle the hypercall and when it's done modify the gprs as
>>>> +necessary. Upon guest entry all guest GPRs will then be replaced by the values
>>>> +in this struct.
>>>> +
>>>>
>>>>
>>> That's migration unsafe. There may not be next guest entry on this host.
>>>
>> It's as unsafe as MMIO then.
>>
>>
>
> From api.txt:
>
>> NOTE: For KVM_EXIT_IO and KVM_EXIT_MMIO, the corresponding operations
>> are complete (and guest state is consistent) only after userspace has
>> re-entered the kernel with KVM_RUN. The kernel side will first finish
>> incomplete operations and then check for pending signals. Userspace
>> can re-enter the guest with an unmasked signal pending to complete
>> pending operations.
>
Alright - so I add KVM_EXIT_OSI there and be good? :)
>
>>> Is using KVM_[GS]ET_REGS problematic for some reason?
>>>
>> It's two additional ioctls for no good reason. We know the interface, so we can model towards it.
>>
>
> But we need to be migration safe. If the interface is not heavily used, let's not add complications.
MOL uses OSI calls instead of MMIO. So yes, it is heavily used.
Alex
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 15/15] KVM: PPC: Make build work without CONFIG_VSX/ALTIVEC
[not found] ` <1268071402-27112-1-git-send-email-agraf-l3A5Bk7waGM@public.gmane.org>
` (7 preceding siblings ...)
2010-03-08 18:03 ` [PATCH 14/15] KVM: PPC: Add OSI hypercall interface Alexander Graf
@ 2010-03-08 18:03 ` Alexander Graf
8 siblings, 0 replies; 30+ messages in thread
From: Alexander Graf @ 2010-03-08 18:03 UTC (permalink / raw)
To: kvm-ppc-u79uwXL29TY76Z2rM5mHXA; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA
The FPU/Altivec/VSX enablement also brought access to some structure
elements that are only defined when the respective config options
are enabled.
Unfortuately I forgot to check for the config options at some places,
so let's do that now.
Unbreaks the build when CONFIG_VSX is not set.
Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
arch/powerpc/kvm/book3s.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index e752a59..00e9684 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -608,7 +608,9 @@ void kvmppc_giveup_ext(struct kvm_vcpu *vcpu, ulong msr)
{
struct thread_struct *t = ¤t->thread;
u64 *vcpu_fpr = vcpu->arch.fpr;
+#ifdef CONFIG_VSX
u64 *vcpu_vsx = vcpu->arch.vsr;
+#endif
u64 *thread_fpr = (u64*)t->fpr;
int i;
@@ -688,7 +690,9 @@ static int kvmppc_handle_ext(struct kvm_vcpu *vcpu, unsigned int exit_nr,
{
struct thread_struct *t = ¤t->thread;
u64 *vcpu_fpr = vcpu->arch.fpr;
+#ifdef CONFIG_VSX
u64 *vcpu_vsx = vcpu->arch.vsr;
+#endif
u64 *thread_fpr = (u64*)t->fpr;
int i;
@@ -1218,8 +1222,12 @@ int __kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
{
int ret;
struct thread_struct ext_bkp;
+#ifdef CONFIG_ALTIVEC
bool save_vec = current->thread.used_vr;
+#endif
+#ifdef CONFIG_VSX
bool save_vsx = current->thread.used_vsr;
+#endif
ulong ext_msr;
/* No need to go into the guest when all we do is going out */
--
1.6.0.2
^ permalink raw reply related [flat|nested] 30+ messages in thread