PAPR virtualization on PR KVM
Subsystems (3)
cover PAPR virtualization on PR KVM
In KVM for Book3S PPC we currently have 2 implementations. There is the PR based implementation which works on any POWER system you pass in and the super fast HV implementation which requires libre firmware (so almost nobody can use it).
Currently, the two target two different machine types, with PR KVM being used for bare metal system virtualization, while the HV KVM is used to virtualize PAPR.
In an effort to make things more cozy and transparent to the user, this patch set implements PAPR capabilities to the PR KVM side, so a user doesn't have to worry what the respective kernel module supports. Any machine he's virtualizing "just works".
Alex
Alexander Graf (10):
KVM: PPC: move compute_tlbie_rb to book3s common header
KVM: PPC: Add papr_enabled flag
KVM: PPC: Check privilege level on SPRs
KVM: PPC: Interpret SDR1 as HVA in PAPR mode
KVM: PPC: Read out syscall instruction on trap
KVM: PPC: Add support for explicit HIOR setting
KVM: PPC: Add PAPR hypercall code for PR mode
KVM: PPC: Stub emulate CFAR and PURR SPRs
KVM: PPC: Support SC1 hypercalls for PAPR in PR mode
KVM: PPC: Enable the PAPR CAP for Book3S
arch/powerpc/include/asm/kvm.h | 8 ++ arch/powerpc/include/asm/kvm_book3s.h | 36 ++++++++ arch/powerpc/include/asm/kvm_host.h | 1 + arch/powerpc/kvm/Makefile | 1 + arch/powerpc/kvm/book3s_64_mmu.c | 8 ++- arch/powerpc/kvm/book3s_emulate.c | 29 ++++++ arch/powerpc/kvm/book3s_hv_rm_mmu.c | 33 ------- arch/powerpc/kvm/book3s_pr.c | 36 +++++++- arch/powerpc/kvm/book3s_pr_papr.c | 158 +++++++++++++++++++++++++++++++++ arch/powerpc/kvm/book3s_segment.S | 5 + arch/powerpc/kvm/powerpc.c | 6 ++ include/linux/kvm.h | 2 + 12 files changed, 286 insertions(+), 37 deletions(-) create mode 100644 arch/powerpc/kvm/book3s_pr_papr.c
PATCH 1/10 KVM: PPC: move compute_tlbie_rb to book3s common header
We need the compute_tlbie_rb in _pr and _hv implementations for papr soon, so let's move it over to a common header file that both implementations can leverage.
--- arch/powerpc/include/asm/kvm_book3s.h | 33 +++++++++++++++++++++++++++++++++ arch/powerpc/kvm/book3s_hv_rm_mmu.c | 33 --------------------------------- 2 files changed, 33 insertions(+), 33 deletions(-)
arch/powerpc/include/asm/kvm_book3s.h +33 -0
@@ -382,6 +382,39 @@ static inline bool kvmppc_critical_section(struct kvm_vcpu *vcpu) }#endif +static inline unsigned long compute_tlbie_rb (unsigned long v,unsigned long r, +unsigned long pte_index) +{ +unsigned long rb, va_low; + + rb = (v & ~0x7fUL ) <<16 ;/* AVA field */ + va_low = pte_index >>3 ; +if (v &HPTE_V_SECONDARY ) + va_low = ~va_low; +/* xor vsid from AVA */ +if (!(v &HPTE_V_1TB_SEG )) + va_low ^= v >>12 ; +else + va_low ^= v >>24 ; + va_low &=0x7ff ; +if (v &HPTE_V_LARGE ) { + rb |=1 ;/* L field */ +if (cpu_has_feature (CPU_FTR_ARCH_206 ) && + (r &0xff000 )) { +/* non-16MB large page, must be 64k */ +/* (masks depend on page size) */ + rb |=0x1000 ;/* page encoding in LP field */ + rb |= (va_low &0x7f ) <<16 ;/* 7b of VA in AVA/LP field */ + rb |= (va_low &0xfe );/* AVAL field (P7 doesn't seem to care) */ + } + }else { +/* 4kB page */ + rb |= (va_low &0x7ff ) <<12 ;/* remaining 11b of VA */ + } + rb |= (v >>54 ) &0x300 ;/* B field */ +return rb; +} +/* Magic register values loaded into r3 and r4 before the 'sc' assembly * instruction for the OSI hypercalls */ #define OSI_SC_MAGIC_R3 0x113724FA
arch/powerpc/kvm/book3s_hv_rm_mmu.c +0 -33
@@ -110,39 +110,6 @@ long kvmppc_h_enter(struct kvm_vcpu *vcpu, unsigned long flags,return H_SUCCESS ; } -static unsigned long compute_tlbie_rb (unsigned long v,unsigned long r, -unsigned long pte_index) -{ -unsigned long rb, va_low; - - rb = (v & ~0x7fUL ) <<16 ;/* AVA field */ - va_low = pte_index >>3 ; -if (v &HPTE_V_SECONDARY ) - va_low = ~va_low; -/* xor vsid from AVA */ -if (!(v &HPTE_V_1TB_SEG )) - va_low ^= v >>12 ; -else - va_low ^= v >>24 ; - va_low &=0x7ff ; -if (v &HPTE_V_LARGE ) { - rb |=1 ;/* L field */ -if (cpu_has_feature (CPU_FTR_ARCH_206 ) && - (r &0xff000 )) { -/* non-16MB large page, must be 64k */ -/* (masks depend on page size) */ - rb |=0x1000 ;/* page encoding in LP field */ - rb |= (va_low &0x7f ) <<16 ;/* 7b of VA in AVA/LP field */ - rb |= (va_low &0xfe );/* AVAL field (P7 doesn't seem to care) */ - } - }else { -/* 4kB page */ - rb |= (va_low &0x7ff ) <<12 ;/* remaining 11b of VA */ - } - rb |= (v >>54 ) &0x300 ;/* B field */ -return rb; -} -#define LOCK_TOKEN (*(u32 *)(&get_paca()->lock_token))static inline int try_lock_tlbie (unsigned int *lock)
Signature · 1 line
1.6.0.2
PATCH 1/1 KVM: PPC: move compute_tlbie_rb to book3s_64 common header
compute_tlbie_rb is only used on ppc64 and cannot be compiled on ppc32.
--- arch/powerpc/include/asm/kvm_book3s.h | 33 ------------------------------ arch/powerpc/include/asm/kvm_book3s_64.h | 33 ++++++++++++++++++++++++++++++ 2 files changed, 33 insertions(+), 33 deletions(-)
arch/powerpc/include/asm/kvm_book3s.h +0 -33
@@ -383,39 +383,6 @@ static inline bool kvmppc_critical_section(struct kvm_vcpu *vcpu) }#endif -static inline unsigned long compute_tlbie_rb (unsigned long v,unsigned long r, -unsigned long pte_index) -{ -unsigned long rb, va_low; - - rb = (v & ~0x7fUL ) <<16 ;/* AVA field */ - va_low = pte_index >>3 ; -if (v &HPTE_V_SECONDARY ) - va_low = ~va_low; -/* xor vsid from AVA */ -if (!(v &HPTE_V_1TB_SEG )) - va_low ^= v >>12 ; -else - va_low ^= v >>24 ; - va_low &=0x7ff ; -if (v &HPTE_V_LARGE ) { - rb |=1 ;/* L field */ -if (cpu_has_feature (CPU_FTR_ARCH_206 ) && - (r &0xff000 )) { -/* non-16MB large page, must be 64k */ -/* (masks depend on page size) */ - rb |=0x1000 ;/* page encoding in LP field */ - rb |= (va_low &0x7f ) <<16 ;/* 7b of VA in AVA/LP field */ - rb |= (va_low &0xfe );/* AVAL field (P7 doesn't seem to care) */ - } - }else { -/* 4kB page */ - rb |= (va_low &0x7ff ) <<12 ;/* remaining 11b of VA */ - } - rb |= (v >>54 ) &0x300 ;/* B field */ -return rb; -} -/* Magic register values loaded into r3 and r4 before the 'sc' assembly * instruction for the OSI hypercalls */ #define OSI_SC_MAGIC_R3 0x113724FA
arch/powerpc/include/asm/kvm_book3s_64.h +33 -0
@@ -29,4 +29,37 @@ static inline struct kvmppc_book3s_shadow_vcpu *to_svcpu(struct kvm_vcpu *vcpu)#define SPAPR_TCE_SHIFT 12 +static inline unsigned long compute_tlbie_rb (unsigned long v,unsigned long r, +unsigned long pte_index) +{ +unsigned long rb, va_low; + + rb = (v & ~0x7fUL ) <<16 ;/* AVA field */ + va_low = pte_index >>3 ; +if (v &HPTE_V_SECONDARY ) + va_low = ~va_low; +/* xor vsid from AVA */ +if (!(v &HPTE_V_1TB_SEG )) + va_low ^= v >>12 ; +else + va_low ^= v >>24 ; + va_low &=0x7ff ; +if (v &HPTE_V_LARGE ) { + rb |=1 ;/* L field */ +if (cpu_has_feature (CPU_FTR_ARCH_206 ) && + (r &0xff000 )) { +/* non-16MB large page, must be 64k */ +/* (masks depend on page size) */ + rb |=0x1000 ;/* page encoding in LP field */ + rb |= (va_low &0x7f ) <<16 ;/* 7b of VA in AVA/LP field */ + rb |= (va_low &0xfe );/* AVAL field (P7 doesn't seem to care) */ + } + }else { +/* 4kB page */ + rb |= (va_low &0x7ff ) <<12 ;/* remaining 11b of VA */ + } + rb |= (v >>54 ) &0x300 ;/* B field */ +return rb; +} +#endif /* __ASM_KVM_BOOK3S_64_H__ */
Signature · 7 lines
1.7.7.2 -- Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Alexander Graf
AppliedRe: [PATCH] KVM: PPC: move compute_tlbie_rb to book3s_64 common header
Quoted 3 lines · Andreas Schwab
compute_tlbie_rbis only used on ppc64 and cannot be compiled on ppc32.Signed-off-by Andreas Schwab<[email protected]>
Thanks, applied to kvm-ppc-next.
Alex
PATCH 2/10 KVM: PPC: Add papr_enabled flag
In reply to Alexander GrafWhen running a PAPR guest, some things change. The privilege level drops from hypervisor to supervisor, SDR1 gets treated differently and we interpret hypercalls. For bisectability sake, add the flag now, but only enable it when all the support code is there.
--- arch/powerpc/include/asm/kvm_host.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
arch/powerpc/include/asm/kvm_host.h +1 -0
@@ -389,6 +389,7 @@ struct kvm_vcpu_arch {u8 dcr_is_write;u8 osi_needed;u8 osi_enabled; +u8 papr_enabled;u8 hcall_needed;u32 cpr0_cfgaddr;/* holds the last set cpr0_cfgaddr */
Signature · 1 line
1.6.0.2
PATCH 3/10 KVM: PPC: Check privilege level on SPRs
In reply to Alexander GrafWe have 3 privilege levels: problem state, supervisor state and hypervisor state. Each of them can access different SPRs, so we need to check on every SPR if it's accessible in the respective mode.
--- arch/powerpc/kvm/book3s_emulate.c | 25 +++++++++++++++++++++++++ 1 files changed, 25 insertions(+), 0 deletions(-)
arch/powerpc/kvm/book3s_emulate.c +25 -0
@@ -63,6 +63,25 @@* function pointers, so let's just disable the define. */ #undef mfsrin +enum priv_level { +PRIV_PROBLEM =0 , +PRIV_SUPER =1 , +PRIV_HYPER =2 , +}; + +static bool spr_allowed (struct kvm_vcpu *vcpu,enum priv_level level) +{ +/* PAPR VMs only access supervisor SPRs */ +if (vcpu->arch.papr_enabled && (level >PRIV_SUPER )) +return false; + +/* Limit user space to its own small SPR set */ +if ((vcpu->arch.shared->msr &MSR_PR ) && level >PRIV_PROBLEM ) +return false; + +return true; +} +int kvmppc_core_emulate_op (struct kvm_run *run,struct kvm_vcpu *vcpu,unsigned int inst,int *advance) {
@@ -296,6 +315,8 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs)switch (sprn) {case SPRN_SDR1 : +if (!spr_allowed (vcpu,PRIV_HYPER )) + goto unprivileged;to_book3s (vcpu)->sdr1 = spr_val;break ;case SPRN_DSISR :
@@ -390,6 +411,7 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs)case SPRN_PMC4_GEKKO :case SPRN_WPAR_GEKKO :break ; +unprivileged:default :printk (KERN_INFO "KVM: invalid SPR write: %d\n" , sprn);#ifndef DEBUG_SPR
@@ -421,6 +443,8 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt)break ; }case SPRN_SDR1 : +if (!spr_allowed (vcpu,PRIV_HYPER )) + goto unprivileged;kvmppc_set_gpr (vcpu, rt,to_book3s (vcpu)->sdr1);break ;case SPRN_DSISR :
@@ -476,6 +500,7 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt)kvmppc_set_gpr (vcpu, rt,0 );break ;default : +unprivileged:printk (KERN_INFO "KVM: invalid SPR read: %d\n" , sprn);#ifndef DEBUG_SPR emulated =EMULATE_FAIL ;
Signature · 1 line
1.6.0.2
PATCH 4/10 KVM: PPC: Interpret SDR1 as HVA in PAPR mode
In reply to Alexander GrafWhen running a PAPR guest, the guest is not allowed to set SDR1 - instead the HTAB information is held in internal hypervisor structures. But all of our current code relies on SDR1 and walking the HTAB like on real hardware.
So in order to not be too intrusive, we simply set SDR1 to the HTAB we hold in host memory. That way we can keep the HTAB in user space, but use it from kernel space to map the guest.
--- arch/powerpc/kvm/book3s_64_mmu.c | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-)
arch/powerpc/kvm/book3s_64_mmu.c +7 -1
@@ -128,7 +128,13 @@ static hva_t kvmppc_mmu_book3s_64_get_pteg(dprintk ("MMU: page=0x%x sdr1=0x%llx pteg=0x%llx vsid=0x%llx\n" , page, vcpu_book3s->sdr1, pteg, slbe->vsid); - r =gfn_to_hva (vcpu_book3s->vcpu.kvm, pteg >>PAGE_SHIFT ); +/* When running a PAPR guest, SDR1 contains a HVA address instead +of a GPA */ +if (vcpu_book3s->vcpu.arch.papr_enabled) + r = pteg; +else + r =gfn_to_hva (vcpu_book3s->vcpu.kvm, pteg >>PAGE_SHIFT ); +if (kvm_is_error_hva (r))return r;return r | (pteg & ~PAGE_MASK );
Signature · 1 line
1.6.0.2
PATCH 5/10 KVM: PPC: Read out syscall instruction on trap
In reply to Alexander GrafWe have a few traps where we cache the instruction that cause the trap for analysis later on. Since we now need to be able to distinguish between SC 0 and SC 1 system calls and the only way to find out which is which is by looking at the instruction, we also read out the instruction causing the system call.
--- arch/powerpc/kvm/book3s_segment.S | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
arch/powerpc/kvm/book3s_segment.S +5 -0
@@ -213,11 +213,16 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE) beq ld_last_inst cmpwi r12, BOOK3S_INTERRUPT_PROGRAM beq ld_last_inst + cmpwi r12, BOOK3S_INTERRUPT_SYSCALL + beq ld_last_prev_inst cmpwi r12, BOOK3S_INTERRUPT_ALIGNMENT beq- ld_last_inst b no_ld_last_inst +ld_last_prev_inst: + addi r3, r3, -4 + ld_last_inst: /* Save off the guest instruction we're at */
Signature · 1 line
1.6.0.2
PATCH 6/10 KVM: PPC: Add support for explicit HIOR setting
In reply to Alexander GrafUntil now, we always set HIOR based on the PVR, but this is just wrong. Instead, we should be setting HIOR explicitly, so user space can decide what the initial HIOR value is - just like on real hardware.
We keep the old PVR based way around for backwards compatibility, but once user space uses the SREGS based method, we drop the PVR logic.
--- arch/powerpc/include/asm/kvm.h | 8 ++++++++ arch/powerpc/include/asm/kvm_book3s.h | 2 ++ arch/powerpc/kvm/book3s_pr.c | 14 ++++++++++++-- arch/powerpc/kvm/powerpc.c | 1 + include/linux/kvm.h | 1 + 5 files changed, 24 insertions(+), 2 deletions(-)
arch/powerpc/include/asm/kvm.h +8 -0
@@ -149,6 +149,12 @@ struct kvm_regs {#define KVM_SREGS_E_UPDATE_DBSR (1 << 3)/* +* Book3S special bits to indicate contents in the struct by maintaining +* backwards compatibility with older structs. If adding a new field, +* please make sure to add a flag for that new field */ +#define KVM_SREGS_S_HIOR (1 << 0) + +/* * In KVM_SET_SREGS, reserved/pad fields must be left untouched from a * previous KVM_GET_REGS. *
@@ -173,6 +179,8 @@ struct kvm_sregs {__u64 ibat[8 ];__u64 dbat[8 ]; } ppc32; +__u64 flags;/* KVM_SREGS_S_ */ +__u64 hior; } s; struct { union {
arch/powerpc/include/asm/kvm_book3s.h +2 -0
@@ -90,6 +90,8 @@ struct kvmppc_vcpu_book3s {#endif int context_id[SID_CONTEXTS ]; +bool hior_sregs;/* HIOR is set by SREGS, not PVR */ +struct hlist_head hpte_hash_pte[HPTEG_HASH_NUM_PTE ];struct hlist_head hpte_hash_pte_long[HPTEG_HASH_NUM_PTE_LONG ];struct hlist_head hpte_hash_vpte[HPTEG_HASH_NUM_VPTE ];
arch/powerpc/kvm/book3s_pr.c +12 -2
@@ -150,13 +150,15 @@ void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)#ifdef CONFIG_PPC_BOOK3S_64 if ((pvr >=0x330000 ) && (pvr <0x70330000 )) {kvmppc_mmu_book3s_64_init (vcpu); -to_book3s (vcpu)->hior =0xfff00000 ; +if (!to_book3s (vcpu)->hior_sregs) +to_book3s (vcpu)->hior =0xfff00000 ;to_book3s (vcpu)->msr_mask =0xffffffffffffffffULL ; } else#endif {kvmppc_mmu_book3s_32_init (vcpu); -to_book3s (vcpu)->hior =0 ; +if (!to_book3s (vcpu)->hior_sregs) +to_book3s (vcpu)->hior =0 ;to_book3s (vcpu)->msr_mask =0xffffffffULL ; }
@@ -770,6 +772,9 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu, } } +if (sregs->u.s.flags &KVM_SREGS_S_HIOR ) + sregs->u.s.hior =to_book3s (vcpu)->hior; +return 0 ; }
@@ -806,6 +811,11 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,/* Flush the MMU after messing with the segments */ kvmppc_mmu_pte_flush (vcpu,0 ,0 ); +if (sregs->u.s.flags &KVM_SREGS_S_HIOR ) { +to_book3s (vcpu)->hior_sregs = true; +to_book3s (vcpu)->hior = sregs->u.s.hior; + } +return 0 ; }
arch/powerpc/kvm/powerpc.c +1 -0
@@ -188,6 +188,7 @@ int kvm_dev_ioctl_check_extension(long ext)case KVM_CAP_PPC_BOOKE_SREGS :#else case KVM_CAP_PPC_SEGSTATE : +case KVM_CAP_PPC_HIOR :#endif case KVM_CAP_PPC_UNSET_IRQ :case KVM_CAP_PPC_IRQ_LEVEL :
include/linux/kvm.h +1 -0
@@ -554,6 +554,7 @@ struct kvm_ppc_pvinfo {#define KVM_CAP_PPC_SMT 64#define KVM_CAP_PPC_RMA 65#define KVM_CAP_MAX_VCPUS 66/* returns max vcpus per vm */ +#define KVM_CAP_PPC_HIOR 67#ifdef KVM_CAP_IRQ_ROUTING
Signature · 1 line
1.6.0.2
PATCH 7/10 KVM: PPC: Add PAPR hypercall code for PR mode
In reply to Alexander GrafWhen running a PAPR guest, we need to handle a few hypercalls in kernel space, most prominently the page table invalidation (to sync the shadows).
So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried to share the code with HV mode, but it ended up being a lot easier this way around, as the two differ too much in those details.
--- arch/powerpc/include/asm/kvm_book3s.h | 1 + arch/powerpc/kvm/Makefile | 1 + arch/powerpc/kvm/book3s_pr_papr.c | 158 +++++++++++++++++++++++++++++++++ 3 files changed, 160 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/kvm/book3s_pr_papr.c
arch/powerpc/include/asm/kvm_book3s.h +1 -0
@@ -150,6 +150,7 @@ 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);extern ulong kvmppc_alignment_dar (struct kvm_vcpu *vcpu,unsigned int inst); +extern int kvmppc_h_pr (struct kvm_vcpu *vcpu,unsigned long cmd);static inline struct kvmppc_vcpu_book3s *to_book3s (struct kvm_vcpu *vcpu) {
arch/powerpc/kvm/Makefile +1 -0
@@ -43,6 +43,7 @@ kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_PR) := \ fpu.o \ book3s_paired_singles.o \ book3s_pr.o \ + book3s_pr_papr.o \ book3s_emulate.o \ book3s_interrupts.o \ book3s_mmu_hpte.o \
arch/powerpc/kvm/book3s_pr_papr.c new file +158 -0
158 lines not on this page · raw message
Signature · 1 line
1.6.0.2
Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
Quoted 16 lines · Alexander Graf
When running a PAPR guest, we need to handle a few hypercalls in kernel space, most prominently the page table invalidation (to sync the shadows).
So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried to share the code with HV mode, but it ended up being a lot easier this way around, as the two differ too much in those details.
+++
b/arch/powerpc/kvm/book3s_pr_papr.carch/powerpc/kvm/book3s_pr_papr.c new file +6
-0@@ -0,0 +1,158 @@ +/* +* Copyright (C) 2011. Freescale Inc. All rights reserved. +* +* Authors: +* Alexander Graf<[email protected]> +* Paul Mackerras<[email protected]>
arch/powerpc/kvm/book3s_pr_papr.c line 16
Quoted 10 lines
arch/powerpc/kvm/book3s_pr_papr.c new file +10
-0+* +* Description: +* +* Hypercall handling for running PAPR guests in PR KVM on Book 3S +* processors. +* +* 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. +*/
Copyright freescale, authors Paul and yourself?
arch/powerpc/kvm/book3s_pr_papr.c line 33
Quoted 13 lines
arch/powerpc/kvm/book3s_pr_papr.c new file +13
-0+ +static unsigned long get_pteg_addr (struct kvm_vcpu *vcpu,long pte_index) +{ +struct kvmppc_vcpu_book3s *vcpu_book3s =to_book3s (vcpu); +unsigned long pteg_addr; + + pte_index<<=4 ; + pte_index&= ((1 << ((vcpu_book3s->sdr1&0x1f ) +11 )) -1 )<<7 |0x70 ; + pteg_addr = vcpu_book3s->sdr1&0xfffffffffffc0000ULL ; + pteg_addr |= pte_index; + +return pteg_addr; +}
Evil space crept in.
Signature · 1 line
error compiling committee.c: too many arguments to function
Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
Quoted 21 lines · Avi Kivity
Quoted 20 lines · Alexander Graf
When running a PAPR guest, we need to handle a few hypercalls in kernel space, most prominently the page table invalidation (to sync the shadows).
So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried to share the code with HV mode, but it ended up being a lot easier this way around, as the two differ too much in those details.
+++
b/arch/powerpc/kvm/book3s_pr_papr.carch/powerpc/kvm/book3s_pr_papr.c new file +10
-0@@ -0,0 +1,158 @@ +/* +* Copyright (C) 2011. Freescale Inc. All rights reserved. +* +* Authors: +* Alexander Graf<[email protected]> +* Paul Mackerras<[email protected]> +* +* Description: +* +* Hypercall handling for running PAPR guests in PR KVM on Book 3S
Quoted 8 lines
arch/powerpc/kvm/book3s_pr_papr.c line 16
Quoted 6 lines
arch/powerpc/kvm/book3s_pr_papr.c new file +6
-0+* processors. +* +* 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. +*/ Copyright freescale, authors Paul and yourself?
Yeah, I'm reasonably clueless when it comes to legal stuff. This code is inspired by Paul's, but is mostly rewritten since it's so tied into the virtual MMU. What would the copyright be in that case?
Quoted 10 lines
Quoted 10 lines
(quoted diff) +2
-0+ +static unsigned long get_pteg_addr(struct kvm_vcpu *vcpu, long
pte_index)arch/powerpc/kvm/book3s_pr_papr.c new file +6
-0+{ +struct kvmppc_vcpu_book3s *vcpu_book3s =to_book3s (vcpu); +unsigned long pteg_addr; + + pte_index<<=4 ; + pte_index&= ((1 << ((vcpu_book3s->sdr1&0x1f ) +11 )) -1 )<<7
Quoted 8 lines
arch/powerpc/kvm/book3s_pr_papr.c line 33
Quoted 6 lines
|
0x70;arch/powerpc/kvm/book3s_pr_papr.c new file +5
-0+ pteg_addr = vcpu_book3s->sdr1&0xfffffffffffc0000ULL ; + pteg_addr |= pte_index; + +return pteg_addr; +}Evil space crept in.
Oh noez! Fixed it :)
Alex
Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
Quoted 32 lines · Alexander Graf
Quoted 22 lines · Avi Kivity
Quoted 21 lines · Alexander Graf
When running a PAPR guest, we need to handle a few hypercalls in kernel space, most prominently the page table invalidation (to sync the shadows).
So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried to share the code with HV mode, but it ended up being a lot easier this way around, as the two differ too much in those details.
+++
b/arch/powerpc/kvm/book3s_pr_papr.carch/powerpc/kvm/book3s_pr_papr.c new file +11
-0@@ -0,0 +1,158 @@ +/* +* Copyright (C) 2011. Freescale Inc. All rights reserved. +* +* Authors: +* Alexander Graf<[email protected]> +* Paul Mackerras<[email protected]> +* +* Description: +* +* Hypercall handling for running PAPR guests in PR KVM on Book 3S +* processors. Quoted 8 lines
Quoted 6 lines
(quoted diff) +2
-0+ * + * This program is free software; you can redistribute it and/ormodify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ */Copyright freescale, authors Paul and yourself?
Quoted 1 line
Yeah, I'm reasonably clueless when it comes to legal stuff. This code is inspired by Paul's, but is mostly rewritten since it's so tied into the virtual MMU. What would the copyright be in that case?
Just put your own (or your employers'). If someone contributed to the code they can add their copyrights (or ask you do do it before inclusion).
It would be good to get Paul's or Ben's so that the unimportant characters between the whitespace get some braintime.
Signature · 1 line
error compiling committee.c: too many arguments to function
Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
Quoted 34 lines · Avi Kivity
Quoted 33 lines · Alexander Graf
Quoted 31 lines · Avi Kivity
Quoted 23 lines · Alexander Graf
When running a PAPR guest, we need to handle a few hypercalls in kernel space, most prominently the page table invalidation (to sync the shadows).
So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried to share the code with HV mode, but it ended up being a lot easier this way around, as the two differ too much in those details.
+++
b/arch/powerpc/kvm/book3s_pr_papr.carch/powerpc/kvm/book3s_pr_papr.c new file +13
-0@@ -0,0 +1,158 @@ +/* +* Copyright (C) 2011. Freescale Inc. All rights reserved. +* +* Authors: +* Alexander Graf<[email protected]> +* Paul Mackerras<[email protected]> +* +* Description: +* +* Hypercall handling for running PAPR guests in PR KVM on Book 3S +* processors. +* +* This program is free software; you can redistribute it and/or Quoted 5 lines
modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ */Copyright freescale, authors Paul and yourself?
Quoted 5 lines
Quoted 1 line
Yeah, I'm reasonably clueless when it comes to legal stuff. This code is inspired by Paul's, but is mostly rewritten since it's so tied into the virtual MMU. What would the copyright be in that case?
Just put your own (or your employers'). If someone contributed to the code they can add their copyrights (or ask you do do it before inclusion).
It would be good to get Paul's or Ben's so that the unimportant characters between the whitespace get some braintime.
So you mean I just put both copyright statements there? That's a nice idea!
Alex
Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
Quoted 4 lines · Alexander Graf
Quoted 4 lines
Just put your own (or your employers'). If someone contributed to the code they can add their copyrights (or ask you do do it before inclusion).
Quoted 8 lines
Quoted 2 lines
It would be good to get Paul's or Ben's so that the unimportant characters between the whitespace get some braintime.
So you mean I just put both copyright statements there? That's a nice idea!
I meant Paul's or Ben's *review*.
Signature · 1 line
error compiling committee.c: too many arguments to function
Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
Quoted 9 lines · Avi Kivity
Quoted 8 lines · Alexander Graf
Quoted 6 lines
Just put your own (or your employers'). If someone contributed to the code they can add their copyrights (or ask you do do it before inclusion).
It would be good to get Paul's or Ben's so that the unimportant characters between the whitespace get some braintime.
Quoted 6 lines
Quoted 4 lines
So you mean I just put both copyright statements there? That's a nice idea!
I meant Paul's or Ben's *review*.
Ben's currently travelling doing some bringup :-) I will try to have a look but I can't promise anything for the next 2 weeks.
Cheers,
Ben.
Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
In reply to Alexander GrafQuoted 6 lines · Alexander Graf
When running a PAPR guest, we need to handle a few hypercalls in kernel space, most prominently the page table invalidation (to sync the shadows).
So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried to share the code with HV mode, but it ended up being a lot easier this way around, as the two differ too much in those details.
Are these strictly necessary, or just an optimization? Because you're using the space allocated by qemu for the guest hash table, it seems to be you could just let h_enter fall through to qemu which will put the right thing into the guest hash table which you can then walk in the kernel translation code.
Signature · 4 lines
David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
Am 12.08.2011 um 05:35 schrieb David Gibson <[email protected]>:
Quoted 8 lines · Alexander Graf
Quoted 6 lines
When running a PAPR guest, we need to handle a few hypercalls in kernel space, most prominently the page table invalidation (to sync the shadows).
So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried to share the code with HV mode, but it ended up being a lot easier this way around, as the two differ too much in those details.
Quoted 5 lines
Are these strictly necessary, or just an optimization? Because you're using the space allocated by qemu for the guest hash table, it seems to be you could just let
h_enterfall through to qemu which will put the right thing into the guest hash table which you can then walk in the kernel translation code.
Every time a PTE can be invalidated, we need to do so in kvm to keep the SPT in sync. IIRC h_enter can evict/overwrite a previous entry, so we need to handle it in kvm as well :). Removal definitely needs to happin in-kernel.
Alex
Quoted 1 line
Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
Quoted 17 lines · Alexander Graf
Am 12.08.2011 um 05:35 schrieb David Gibson <[email protected]>:
Quoted 8 lines · Alexander Graf
Quoted 6 lines
When running a PAPR guest, we need to handle a few hypercalls in kernel space, most prominently the page table invalidation (to sync the shadows).
So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried to share the code with HV mode, but it ended up being a lot easier this way around, as the two differ too much in those details.
Quoted 5 lines
Are these strictly necessary, or just an optimization? Because you're using the space allocated by qemu for the guest hash table, it seems to be you could just let
h_enterfall through to qemu which will put the right thing into the guest hash table which you can then walk in the kernel translation code.
Quoted 4 lines
Every time a PTE can be invalidated, we need to do so in kvm to keep the SPT in sync. IIRC
h_entercan evict/overwrite a previous entry, so we need to handle it in kvm as well :). Removal definitely needs to happin in-kernel.
True. I think you could actually delay this invalidation until the guest issues the tlbie, but it's probably not worth it.
Signature · 4 lines
David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
Am 12.08.2011 um 09:43 schrieb David Gibson <[email protected]>:
Quoted 18 lines · Alexander Graf
Quoted 17 lines
Am 12.08.2011 um 05:35 schrieb David Gibson <[email protected]>:
Quoted 13 lines · Alexander Graf
Quoted 6 lines
When running a PAPR guest, we need to handle a few hypercalls in kernel space, most prominently the page table invalidation (to sync the shadows).
So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried to share the code with HV mode, but it ended up being a lot easier this way around, as the two differ too much in those details.
Are these strictly necessary, or just an optimization? Because you're using the space allocated by qemu for the guest hash table, it seems to be you could just let
h_enterfall through to qemu which will put the right thing into the guest hash table which you can then walk in the kernel translation code.
Quoted 7 lines
Quoted 4 lines
Every time a PTE can be invalidated, we need to do so in kvm to keep the SPT in sync. IIRC
h_entercan evict/overwrite a previous entry, so we need to handle it in kvm as well :). Removal definitely needs to happin in-kernel.True. I think you could actually delay this invalidation until the guest issues the tlbie, but it's probably not worth it.
Well, since we need to have HTAB modification code in kvm for PR either way, I'd rather have all of it at the same place :)
Alex
PATCH 8/10 KVM: PPC: Stub emulate CFAR and PURR SPRs
In reply to Alexander GrafRecent Linux versions use the CFAR and PURR SPRs, but don't really care about their contents (yet). So for now, we can simply return 0 when the guest wants to read them.
--- arch/powerpc/kvm/book3s_emulate.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
arch/powerpc/kvm/book3s_emulate.c +4 -0
@@ -473,6 +473,10 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt)case SPRN_HID5 :kvmppc_set_gpr (vcpu, rt,to_book3s (vcpu)->hid[5 ]);break ; +case SPRN_CFAR : +case SPRN_PURR : +kvmppc_set_gpr (vcpu, rt,0 ); +break ;case SPRN_GQR0 :case SPRN_GQR1 :case SPRN_GQR2 :
Signature · 1 line
1.6.0.2
PATCH 9/10 KVM: PPC: Support SC1 hypercalls for PAPR in PR mode
In reply to Alexander GrafPAPR defines hypercalls as SC1 instructions. Using these, the guest modifies page tables and does other privileged operations that it wouldn't be allowed to do in supervisor mode.
This patch adds support for PR KVM to trap these instructions and route them through the same PAPR hypercall interface that we already use for HV style KVM.
--- arch/powerpc/kvm/book3s_pr.c | 22 +++++++++++++++++++++- 1 files changed, 21 insertions(+), 1 deletions(-)
arch/powerpc/kvm/book3s_pr.c +21 -1
@@ -648,7 +648,27 @@ program_interrupt:break ; }case BOOK3S_INTERRUPT_SYSCALL : -if (vcpu->arch.osi_enabled && +if (vcpu->arch.papr_enabled && + (kvmppc_get_last_inst (vcpu) =0x44000022 ) && + !(vcpu->arch.shared->msr &MSR_PR )) { +/* SC 1 papr hypercalls */ +ulong cmd =kvmppc_get_gpr (vcpu,3 ); +int i; + +if (kvmppc_h_pr (vcpu, cmd) =EMULATE_DONE ) { + r =RESUME_GUEST ; +break ; + } + + run->papr_hcall.nr = cmd; +for (i =0 ; i <9 ; ++i) { +ulong gpr =kvmppc_get_gpr (vcpu,4 + i); + run->papr_hcall.args[i] = gpr; + } + run->exit_reason =KVM_EXIT_PAPR_HCALL ; + vcpu->arch.hcall_needed =1 ; + r =RESUME_HOST ; + }else 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 )) {/* MOL hypercalls */
Signature · 1 line
1.6.0.2
Re: [PATCH 09/10] KVM: PPC: Support SC1 hypercalls for PAPR in PR mode
Quoted 7 lines · Alexander Graf
PAPR defines hypercalls as SC1 instructions. Using these, the guest modifies page tables and does other privileged operations that it wouldn't be allowed to do in supervisor mode.
This patch adds support for PR KVM to trap these instructions and route them through the same PAPR hypercall interface that we already use for HV style KVM.
This will work on a powermac or bare metal host. Unfortunately, it's not enough on a pSeries LPAR host - the sc 1 instruction from the guest problem state will go direct to the hypervisor, which will return an error rather than trapping to the guest kernel.
The only way around this I can see is for qemu to search for and patch up sc 1 instructions to something else. Obviously that would also need some kernel support, and probably a capability to let it know if it's necessary.
Signature · 4 lines
David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Re: [PATCH 09/10] KVM: PPC: Support SC1 hypercalls for PAPR in PR mode
Am 12.08.2011 um 05:33 schrieb David Gibson <[email protected]>:
Quoted 14 lines · Alexander Graf
Quoted 7 lines
PAPR defines hypercalls as SC1 instructions. Using these, the guest modifies page tables and does other privileged operations that it wouldn't be allowed to do in supervisor mode.
This patch adds support for PR KVM to trap these instructions and route them through the same PAPR hypercall interface that we already use for HV style KVM.
This will work on a powermac or bare metal host. Unfortunately, it's not enough on a pSeries LPAR host - the sc 1 instruction from the guest problem state will go direct to the hypervisor, which will return an error rather than trapping to the guest kernel.
Quoted 4 lines
The only way around this I can see is for qemu to search for and patch up sc 1 instructions to something else. Obviously that would also need some kernel support, and probably a capability to let it know if it's necessary.
Well I'd like to keep Qemu out of the patching business, so the guest kernel would have to patch itself. But yes, PHyP guests can't run this target yet :). I'll take a stab at that too, but one continent at a time! ;)
Alex
Quoted 1 line
Re: [PATCH 09/10] KVM: PPC: Support SC1 hypercalls for PAPR in PR mode
Quoted 17 lines · Alexander Graf
Am 12.08.2011 um 05:33 schrieb David Gibson <[email protected]>:
Quoted 14 lines · Alexander Graf
Quoted 7 lines
PAPR defines hypercalls as SC1 instructions. Using these, the guest modifies page tables and does other privileged operations that it wouldn't be allowed to do in supervisor mode.
This patch adds support for PR KVM to trap these instructions and route them through the same PAPR hypercall interface that we already use for HV style KVM.
This will work on a powermac or bare metal host. Unfortunately, it's not enough on a pSeries LPAR host - the sc 1 instruction from the guest problem state will go direct to the hypervisor, which will return an error rather than trapping to the guest kernel.
Quoted 7 lines
Quoted 4 lines
The only way around this I can see is for qemu to search for and patch up sc 1 instructions to something else. Obviously that would also need some kernel support, and probably a capability to let it know if it's necessary.
Well I'd like to keep Qemu out of the patching business, so the guest kernel would have to patch itself.
Well sure, but guest patching itself means it can't run existing kernels. I thought qemu already patched a few things, ugly though that approach is.
Quoted 3 lines
But yes, PHyP guests can't
run this target yet :). I'll take a stab at that too, but one continent at a time! ;)
Signature · 4 lines
David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Re: [PATCH 09/10] KVM: PPC: Support SC1 hypercalls for PAPR in PR mode
Am 12.08.2011 um 09:43 schrieb David Gibson <[email protected]>:
Quoted 23 lines · Alexander Graf
Quoted 22 lines
Am 12.08.2011 um 05:33 schrieb David Gibson <[email protected]>:
Quoted 18 lines · Alexander Graf
Quoted 7 lines
PAPR defines hypercalls as SC1 instructions. Using these, the guest modifies page tables and does other privileged operations that it wouldn't be allowed to do in supervisor mode.
This patch adds support for PR KVM to trap these instructions and route them through the same PAPR hypercall interface that we already use for HV style KVM.
This will work on a powermac or bare metal host. Unfortunately, it's not enough on a pSeries LPAR host - the sc 1 instruction from the guest problem state will go direct to the hypervisor, which will return an error rather than trapping to the guest kernel.
The only way around this I can see is for qemu to search for and patch up sc 1 instructions to something else. Obviously that would also need some kernel support, and probably a capability to let it know if it's necessary.
Quoted 6 lines
Quoted 2 lines
Well I'd like to keep Qemu out of the patching business, so the guest kernel would have to patch itself.
Well sure, but guest patching itself means it can't run existing kernels. I thought qemu already patched a few things, ugly though that approach is.
Nope, qemu doesn't patch guest code by itself. The only time the guest kernel doesn't patch itself is the TPR acceleration for Windows - because we can't modify the guest here.
I also don't think it's that important to support older Linux guests if it means we need to patch the guest from the outside :). If you really need to use PHyP, just run a newer guest kernel or -M mac99.
One thing I agree with though is that we should fail the CAP enable if we run on broken hypervisors.
Alex
Quoted 1 line
PATCH 1/1 KVM: PPC: protect use of kvmppc_h_pr
In reply to Alexander Grafkvmppc_h_pr is only available if CONFIG_KVM_BOOK3S_64_PR.
--- arch/powerpc/kvm/book3s_pr.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
arch/powerpc/kvm/book3s_pr.c +2 -0
@@ -660,10 +660,12 @@ program_interrupt:ulong cmd =kvmppc_get_gpr (vcpu,3 );int i; +#ifdef CONFIG_KVM_BOOK3S_64_PR if (kvmppc_h_pr (vcpu, cmd) =EMULATE_DONE ) { r =RESUME_GUEST ;break ; } +#endif run->papr_hcall.nr = cmd;for (i =0 ; i <9 ; ++i) {
Signature · 7 lines
1.7.7.2 -- Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Alexander Graf
AppliedRe: [PATCH] KVM: PPC: protect use of kvmppc_h_pr
Quoted 3 lines · Andreas Schwab
kvmppc_h_pris only available ifCONFIG_KVM_BOOK3S_64_PR.Signed-off-by Andreas Schwab<[email protected]>
Thanks, applied to kvm-ppc-next.
Alex
PATCH 10/10 KVM: PPC: Enable the PAPR CAP for Book3S
In reply to Alexander GrafNow that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR mode.
--- arch/powerpc/kvm/powerpc.c | 5 +++++ include/linux/kvm.h | 1 + 2 files changed, 6 insertions(+), 0 deletions(-)
arch/powerpc/kvm/powerpc.c +5 -0
@@ -189,6 +189,7 @@ int kvm_dev_ioctl_check_extension(long ext)#else case KVM_CAP_PPC_SEGSTATE :case KVM_CAP_PPC_HIOR : +case KVM_CAP_PPC_PAPR :#endif case KVM_CAP_PPC_UNSET_IRQ :case KVM_CAP_PPC_IRQ_LEVEL :
@@ -572,6 +573,10 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu, r =0 ; vcpu->arch.osi_enabled = true;break ; +case KVM_CAP_PPC_PAPR : + r =0 ; + vcpu->arch.papr_enabled = true; +break ;default : r = -EINVAL ;break ;
include/linux/kvm.h +1 -0
@@ -555,6 +555,7 @@ struct kvm_ppc_pvinfo {#define KVM_CAP_PPC_RMA 65#define KVM_CAP_MAX_VCPUS 66/* returns max vcpus per vm */ #define KVM_CAP_PPC_HIOR 67 +#define KVM_CAP_PPC_PAPR 68#ifdef KVM_CAP_IRQ_ROUTING
Signature · 1 line
1.6.0.2
Re: [PATCH 10/10] KVM: PPC: Enable the PAPR CAP for Book3S
Quoted 3 lines · Alexander Graf
Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR mode.
Don't we want to enable it only for 64-bit hosts? Trying to run a PAPR guest on a 32-bit Book 3S host won't work very well, unless I am missing something...
Regards,
Paul.
Re: [PATCH 10/10] KVM: PPC: Enable the PAPR CAP for Book3S
Am 10.08.2011 um 06:42 schrieb Paul Mackerras <[email protected]>:
Quoted 9 lines · Alexander Graf
Quoted 4 lines
Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR mode.
Don't we want to enable it only for 64-bit hosts? Trying to run a PAPR guest on a 32-bit Book 3S host won't work very well, unless I am missing something...
I agree that it doesn't make sense, but if anything we should restrict it to 64-bit _guests_. you can also run 32-bit guests on 64-bit hosts.
And so far, we don't have a single interface setting PVR and PAPR mode at the same time, so you could still enable PAPR with a 64-bit guest CPU and then switch to a 32-bit CPU.
It'd be a nightmare to check all configurations on every setter function.
Unless...
We could introduce a sanity check function that gets executed every time we change PVR or enable PAPR. That could set a variable in the vcpu struct to indicate that the config is ok. We could then check that on vcpu_run.
Alex
Quoted 1 line
Re: [PATCH 10/10] KVM: PPC: Enable the PAPR CAP for Book3S
Quoted 9 lines · Alexander Graf
Am 10.08.2011 um 06:42 schrieb Paul Mackerras <[email protected]>:
Quoted 6 lines · Alexander Graf
Quoted 4 lines
Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR mode.
Quoted 7 lines
Quoted 3 lines
Don't we want to enable it only for 64-bit hosts? Trying to run a PAPR guest on a 32-bit Book 3S host won't work very well, unless I am missing something...
I agree that it doesn't make sense, but if anything we should restrict it to 64-bit _guests_. you can also run 32-bit guests on 64-bit hosts.
I had a look in PAPR and I didn't find anything that says the processor has to be 64-bit, so I guess a 32-bit PAPR guest is possible in theory. However, I don't think there are currently any 32-bit PAPR operating systems that would use hcalls.
Quoted 4 lines
And so far, we don't have a single interface setting PVR and PAPR mode at the same time, so you could still enable PAPR with a 64-bit guest CPU and then switch to a 32-bit CPU.
Quoted 8 lines
It'd be a nightmare to check all configurations on every setter function.
Unless...
We could introduce a sanity check function that gets executed every time we change PVR or enable PAPR. That could set a variable in the vcpu struct to indicate that the config is ok. We could then check that on
vcpu_run.
It's probably not worth worrying about it.
The rest of the series looks very nice.
Regards,
Paul.
Re: [PATCH 10/10] KVM: PPC: Enable the PAPR CAP for Book3S
Quoted 11 lines · Paul Mackerras
Quoted 10 lines · Alexander Graf
Am 10.08.2011 um 06:42 schrieb Paul Mackerras<[email protected]>:
Quoted 8 lines · Alexander Graf
Quoted 4 lines
Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR mode.
Don't we want to enable it only for 64-bit hosts? Trying to run a PAPR guest on a 32-bit Book 3S host won't work very well, unless I am missing something...
Quoted 7 lines
Quoted 3 lines
I agree that it doesn't make sense, but if anything we should restrict it to 64-bit _guests_. you can also run 32-bit guests on 64-bit hosts.
I had a look in PAPR and I didn't find anything that says the processor has to be 64-bit, so I guess a 32-bit PAPR guest is possible in theory. However, I don't think there are currently any 32-bit PAPR operating systems that would use hcalls.
That's what I figured :). The code flow we're affecting here is pretty much generic.
Quoted 6 lines
Quoted 6 lines
And so far, we don't have a single interface setting PVR and PAPR mode at the same time, so you could still enable PAPR with a 64-bit guest CPU and then switch to a 32-bit CPU.
It'd be a nightmare to check all configurations on every setter function.
Quoted 7 lines
Quoted 6 lines
Unless...
We could introduce a sanity check function that gets executed every time we change PVR or enable PAPR. That could set a variable in the vcpu struct to indicate that the config is ok. We could then check that on
vcpu_run.It's probably not worth worrying about it.
Too late, already implemented it :). It really does make sense to have some sort of checking here - even if it only means that our hypercall implementation can't handle it yet or that we didn't test it. And we can put the "HV KVM can only run PAPR" check in there as well.
Alex
Quoted 4 lines · Alexander Graf
In KVM for Book3S PPC we currently have 2 implementations. There is the PR based implementation which works on any POWER system you pass in and the super fast HV implementation which requires libre firmware (so almost nobody can use it).
Did you mean, non-libre?
Quoted 10 lines
Currently, the two target two different machine types, with PR KVM being used for bare metal system virtualization, while the HV KVM is used to virtualize PAPR.
In an effort to make things more cozy and transparent to the user, this patch set implements PAPR capabilities to the PR KVM side, so a user doesn't have to worry what the respective kernel module supports. Any machine he's virtualizing "just works".
Nice. I went though it and nothing shouted "I'm wrong, kill me please", though I don't claim to understand more than 5% of it.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 7 lines · Avi Kivity
Quoted 4 lines · Alexander Graf
In KVM for Book3S PPC we currently have 2 implementations. There is the PR based implementation which works on any POWER system you pass in and the super fast HV implementation which requires libre firmware (so almost nobody can use it).
Did you mean, non-libre?
No, I did mean libre :). Usually firmware on IBM POWER systems already uses the hypervisor mode for itself, so we can't leverage it. The only system that is publicly available and can run HV KVM is the YDL PowerStation which is running SLOF, an open source firmware.
Quoted 6 lines
Quoted 6 lines
Currently, the two target two different machine types, with PR KVM being used for bare metal system virtualization, while the HV KVM is used to virtualize PAPR.
Quoted 7 lines
Quoted 5 lines
In an effort to make things more cozy and transparent to the user, this patch set implements PAPR capabilities to the PR KVM side, so a user doesn't have to worry what the respective kernel module supports. Any machine he's virtualizing "just works".
Nice. I went though it and nothing shouted "I'm wrong, kill me please", though I don't claim to understand more than 5% of it.
Heh :). The thing giving me the most headaches here is the ENABLE_CAP part on PAPR. I'd love to have a more flexible framework there that can configure kvm into the right mode of operation completely, so we get the chance of passing back "Sorry, that mode doesn't work for me" at the end of the day.
But I guess we can just do that with the cap enablings too. It's just slightly more icky.
Alex
[PATCH 11/10] KVM: PPC: Add sanity checking to vcpu_run
In reply to Alexander GrafThere are multiple features in PowerPC KVM that can now be enabled depending on the user's wishes. Some of the combinations don't make sense or don't work though.
So this patch adds a way to check if the executing environment would actually be able to run the guest properly. It also adds sanity checks if PVR is set (should always be true given the current code flow), if PAPR is only used with book3s_64 where it works and that HV KVM is only used in PAPR mode.
--- arch/powerpc/include/asm/kvm.h | 5 +++++ arch/powerpc/include/asm/kvm_host.h | 2 ++ arch/powerpc/include/asm/kvm_ppc.h | 1 + arch/powerpc/kvm/44x.c | 2 ++ arch/powerpc/kvm/book3s_hv.c | 8 ++++++++ arch/powerpc/kvm/book3s_pr.c | 10 ++++++++++ arch/powerpc/kvm/booke.c | 10 +++++++++- arch/powerpc/kvm/e500.c | 2 ++ arch/powerpc/kvm/powerpc.c | 28 ++++++++++++++++++++++++++++ 9 files changed, 67 insertions(+), 1 deletions(-)
arch/powerpc/include/asm/kvm.h +5 -0
@@ -284,6 +284,11 @@ struct kvm_guest_debug_arch {#define KVM_INTERRUPT_UNSET -2U#define KVM_INTERRUPT_SET_LEVEL -3U +#define KVM_CPU_440 1 +#define KVM_CPU_E500V2 2 +#define KVM_CPU_3S_32 3 +#define KVM_CPU_3S_64 4 +/* for KVM_CAP_SPAPR_TCE */ struct kvm_create_spapr_tce {__u64 liobn;
arch/powerpc/include/asm/kvm_host.h +2 -0
@@ -390,6 +390,8 @@ struct kvm_vcpu_arch {u8 osi_needed;u8 osi_enabled;u8 papr_enabled; +u8 sane; +u8 cpu_type;u8 hcall_needed;u32 cpr0_cfgaddr;/* holds the last set cpr0_cfgaddr */
arch/powerpc/include/asm/kvm_ppc.h +1 -0
@@ -66,6 +66,7 @@ extern int kvmppc_emulate_instruction(struct kvm_run *run,extern int kvmppc_emulate_mmio (struct kvm_run *run,struct kvm_vcpu *vcpu);extern void kvmppc_emulate_dec (struct kvm_vcpu *vcpu);extern u32 kvmppc_get_dec (struct kvm_vcpu *vcpu,u64 tb); +extern int kvmppc_sanity_check (struct kvm_vcpu *vcpu);/* Core-specific hooks */
arch/powerpc/kvm/44x.c +2 -0
@@ -78,6 +78,8 @@ int kvmppc_core_vcpu_setup(struct kvm_vcpu *vcpu)for (i =0 ; i <ARRAY_SIZE (vcpu_44x->shadow_refs); i++) vcpu_44x->shadow_refs[i].gtlb_index =-1 ; + vcpu->arch.cpu_type =KVM_CPU_440 ; +return 0 ; }
arch/powerpc/kvm/book3s_hv.c +8 -0
@@ -510,6 +510,9 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id)spin_unlock (&vcore->lock); vcpu->arch.vcore = vcore; + vcpu->arch.cpu_type =KVM_CPU_3S_64 ; +kvmppc_sanity_check (vcpu); +return vcpu; free_vcpu:
@@ -800,6 +803,11 @@ int kvmppc_vcpu_run(struct kvm_run *run, struct kvm_vcpu *vcpu) {int r; +if (!vcpu->arch.sane) { + kvm_run->exit_reason =KVM_EXIT_INTERNAL_ERROR ; +return -EINVAL ; + } + do { r = kvmppc_run_vcpu(run, vcpu);
arch/powerpc/kvm/book3s_pr.c +10 -0
@@ -153,6 +153,7 @@ void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)if (!to_book3s (vcpu)->hior_sregs)to_book3s (vcpu)->hior =0xfff00000 ;to_book3s (vcpu)->msr_mask =0xffffffffffffffffULL ; + vcpu->arch.cpu_type =KVM_CPU_3S_64 ; } else#endif {
@@ -160,8 +161,11 @@ void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)if (!to_book3s (vcpu)->hior_sregs)to_book3s (vcpu)->hior =0 ;to_book3s (vcpu)->msr_mask =0xffffffffULL ; + vcpu->arch.cpu_type =KVM_CPU_3S_32 ; } +kvmppc_sanity_check (vcpu); +/* If we are in hypervisor level on 970, we can tell the CPU to * treat DCBZ as 32 bytes store */ vcpu->arch.hflags &= ~BOOK3S_HFLAG_DCBZ32 ;
@@ -938,6 +942,12 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)#endif ulong ext_msr; +/* Check if we can run the vcpu at all */ +if (!vcpu->arch.sane) { + kvm_run->exit_reason =KVM_EXIT_INTERNAL_ERROR ; +return -EINVAL ; + } +/* No need to go into the guest when all we do is going out */ if (signal_pending (current)) { kvm_run->exit_reason =KVM_EXIT_INTR ;
arch/powerpc/kvm/booke.c +9 -1
@@ -316,6 +316,11 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu) {int ret; +if (!vcpu->arch.sane) { + kvm_run->exit_reason =KVM_EXIT_INTERNAL_ERROR ; +return -EINVAL ; + } +local_irq_disable ();kvm_guest_enter (); ret =__kvmppc_vcpu_run (kvm_run, vcpu);
@@ -618,6 +623,7 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,int kvm_arch_vcpu_setup (struct kvm_vcpu *vcpu) {int i; +int r; vcpu->arch.pc =0 ; vcpu->arch.shared->msr =0 ;
@@ -634,7 +640,9 @@ int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)kvmppc_init_timing_stats (vcpu); -return kvmppc_core_vcpu_setup (vcpu); + r =kvmppc_core_vcpu_setup (vcpu); +kvmppc_sanity_check (vcpu); +return r; }int kvm_arch_vcpu_ioctl_get_regs (struct kvm_vcpu *vcpu,struct kvm_regs *regs)
arch/powerpc/kvm/e500.c +2 -0
@@ -73,6 +73,8 @@ int kvmppc_core_vcpu_setup(struct kvm_vcpu *vcpu)/* Since booke kvm only support one core, update all vcpus' PIR to 0 */ vcpu->vcpu_id =0 ; + vcpu->arch.cpu_type =KVM_CPU_E500V2 ; +return 0 ; }
arch/powerpc/kvm/powerpc.c +28 -0
@@ -95,6 +95,31 @@ int kvmppc_kvm_pv(struct kvm_vcpu *vcpu)return r; } +int kvmppc_sanity_check (struct kvm_vcpu *vcpu) +{ +int r = false; + +/* We have to know what CPU to virtualize */ +if (!vcpu->arch.pvr) + goto out; + +/* PAPR only works with book3s_64 */ +if ((vcpu->arch.cpu_type !=KVM_CPU_3S_64 ) && vcpu->arch.papr_enabled) + goto out; + +#ifdef CONFIG_KVM_BOOK3S_64_HV +/* HV KVM can only do PAPR mode for now */ +if (!vcpu->arch.papr_enabled) + goto out; +#endif + + r = true; + +out: + vcpu->arch.sane = r; +return r ?0 : -EINVAL ; +} +int kvmppc_emulate_mmio (struct kvm_run *run,struct kvm_vcpu *vcpu) {enum emulation_result er;
@@ -582,6 +607,9 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,break ; } +if (!r) + r =kvmppc_sanity_check (vcpu); +return r; }
Signature · 1 line
1.6.0.2