From: Alexander Graf <hidden> Date: 2011-08-09 16:31:55
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
From: Alexander Graf <hidden> Date: 2011-08-09 16:31:55
We 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.
Signed-off-by: Alexander Graf <redacted>
---
arch/powerpc/kvm/book3s_segment.S | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
From: Alexander Graf <hidden> Date: 2011-08-09 16:31:55
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.
Signed-off-by: Alexander Graf <redacted>
---
arch/powerpc/include/asm/kvm_book3s.h | 33 +++++++++++++++++++++++++++++++++
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 33 ---------------------------------
2 files changed, 33 insertions(+), 33 deletions(-)
@@ -382,6 +382,39 @@ static inline bool kvmppc_critical_section(struct kvm_vcpu *vcpu)}#endif+staticinlineunsignedlongcompute_tlbie_rb(unsignedlongv,unsignedlongr,+unsignedlongpte_index)+{+unsignedlongrb,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 */+returnrb;+}+/* Magic register values loaded into r3 and r4 before the 'sc' assembly*instructionfortheOSIhypercalls*/#define OSI_SC_MAGIC_R3 0x113724FA
@@ -110,39 +110,6 @@ long kvmppc_h_enter(struct kvm_vcpu *vcpu, unsigned long flags,returnH_SUCCESS;}-staticunsignedlongcompute_tlbie_rb(unsignedlongv,unsignedlongr,-unsignedlongpte_index)-{-unsignedlongrb,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 */-returnrb;-}-#define LOCK_TOKEN (*(u32 *)(&get_paca()->lock_token))staticinlineinttry_lock_tlbie(unsignedint*lock)
From: Alexander Graf <hidden> Date: 2011-08-09 16:31:55
When 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.
Signed-off-by: Alexander Graf <redacted>
---
arch/powerpc/include/asm/kvm_host.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
@@ -389,6 +389,7 @@ struct kvm_vcpu_arch {u8dcr_is_write;u8osi_needed;u8osi_enabled;+u8papr_enabled;u8hcall_needed;u32cpr0_cfgaddr;/* holds the last set cpr0_cfgaddr */
From: Alexander Graf <hidden> Date: 2011-08-09 16:31:55
When 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.
Signed-off-by: Alexander Graf <redacted>
---
arch/powerpc/kvm/book3s_64_mmu.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
From: Alexander Graf <hidden> Date: 2011-08-09 16:32:00
We 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.
Signed-off-by: Alexander Graf <redacted>
---
arch/powerpc/kvm/book3s_emulate.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
@@ -63,6 +63,25 @@*functionpointers,solet'sjustdisablethedefine.*/#undef mfsrin+enumpriv_level{+PRIV_PROBLEM=0,+PRIV_SUPER=1,+PRIV_HYPER=2,+};++staticboolspr_allowed(structkvm_vcpu*vcpu,enumpriv_levellevel)+{+/* PAPR VMs only access supervisor SPRs */+if(vcpu->arch.papr_enabled&&(level>PRIV_SUPER))+returnfalse;++/* Limit user space to its own small SPR set */+if((vcpu->arch.shared->msr&MSR_PR)&&level>PRIV_PROBLEM)+returnfalse;++returntrue;+}+intkvmppc_core_emulate_op(structkvm_run*run,structkvm_vcpu*vcpu,unsignedintinst,int*advance){
@@ -296,6 +315,8 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs)switch(sprn){caseSPRN_SDR1:+if(!spr_allowed(vcpu,PRIV_HYPER))+gotounprivileged;to_book3s(vcpu)->sdr1=spr_val;break;caseSPRN_DSISR:
@@ -390,6 +411,7 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs)caseSPRN_PMC4_GEKKO:caseSPRN_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;}caseSPRN_SDR1:+if(!spr_allowed(vcpu,PRIV_HYPER))+gotounprivileged;kvmppc_set_gpr(vcpu,rt,to_book3s(vcpu)->sdr1);break;caseSPRN_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_SPRemulated=EMULATE_FAIL;
From: Alexander Graf <hidden> Date: 2011-08-09 16:32:00
Recent 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.
Signed-off-by: Alexander Graf <redacted>
---
arch/powerpc/kvm/book3s_emulate.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
@@ -473,6 +473,10 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt)caseSPRN_HID5:kvmppc_set_gpr(vcpu,rt,to_book3s(vcpu)->hid[5]);break;+caseSPRN_CFAR:+caseSPRN_PURR:+kvmppc_set_gpr(vcpu,rt,0);+break;caseSPRN_GQR0:caseSPRN_GQR1:caseSPRN_GQR2:
From: Alexander Graf <hidden> Date: 2011-08-09 16:32:00
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.
Signed-off-by: Alexander Graf <redacted>
---
arch/powerpc/kvm/book3s_pr.c | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
From: Alexander Graf <hidden> Date: 2011-08-09 16:32:00
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.
Signed-off-by: Alexander Graf <redacted>
---
arch/powerpc/kvm/powerpc.c | 5 +++++
include/linux/kvm.h | 1 +
2 files changed, 6 insertions(+), 0 deletions(-)
From: Alexander Graf <hidden> Date: 2011-08-09 16:32:00
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.
Signed-off-by: Alexander Graf <redacted>
---
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
@@ -0,0 +1,158 @@+/*+*Copyright(C)2011.FreescaleInc.Allrightsreserved.+*+*Authors:+*AlexanderGraf<agraf@suse.de>+*PaulMackerras<paulus@samba.org>+*+*Description:+*+*HypercallhandlingforrunningPAPRguestsinPRKVMonBook3S+*processors.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodify+*itunderthetermsoftheGNUGeneralPublicLicense,version2,as+*publishedbytheFreeSoftwareFoundation.+*/++#include<asm/uaccess.h>+#include<asm/kvm_ppc.h>+#include<asm/kvm_book3s.h>++staticunsignedlongget_pteg_addr(structkvm_vcpu*vcpu,longpte_index)+{+structkvmppc_vcpu_book3s*vcpu_book3s=to_book3s(vcpu);+unsignedlongpteg_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;++returnpteg_addr;+}++staticintkvmppc_h_pr_enter(structkvm_vcpu*vcpu)+{+longflags=kvmppc_get_gpr(vcpu,4);+longpte_index=kvmppc_get_gpr(vcpu,5);+unsignedlongpteg[2*8];+unsignedlongpteg_addr,i,*hpte;++pte_index&=~7UL;+pteg_addr=get_pteg_addr(vcpu,pte_index);++copy_from_user(pteg,(void__user*)pteg_addr,sizeof(pteg));+hpte=pteg;++if(likely((flags&H_EXACT)==0)){+pte_index&=~7UL;+for(i=0;;++i){+if(i==8)+returnH_PTEG_FULL;+if((*hpte&HPTE_V_VALID)==0)+break;+hpte+=2;+}+}else{+i=kvmppc_get_gpr(vcpu,5)&7UL;+hpte+=i*2;+}++hpte[0]=kvmppc_get_gpr(vcpu,6);+hpte[1]=kvmppc_get_gpr(vcpu,7);+copy_to_user((void__user*)pteg_addr,pteg,sizeof(pteg));+kvmppc_set_gpr(vcpu,3,H_SUCCESS);+kvmppc_set_gpr(vcpu,4,pte_index|i);++returnEMULATE_DONE;+}++staticintkvmppc_h_pr_remove(structkvm_vcpu*vcpu)+{+unsignedlongflags=kvmppc_get_gpr(vcpu,4);+unsignedlongpte_index=kvmppc_get_gpr(vcpu,5);+unsignedlongavpn=kvmppc_get_gpr(vcpu,6);+unsignedlongv=0,pteg,rb;+unsignedlongpte[2];++pteg=get_pteg_addr(vcpu,pte_index);+copy_from_user(pte,(void__user*)pteg,sizeof(pte));++if((pte[0]&HPTE_V_VALID)==0||+((flags&H_AVPN)&&(pte[0]&~0x7fUL)!=avpn)||+((flags&H_ANDCOND)&&(pte[0]&avpn)!=0)){+kvmppc_set_gpr(vcpu,3,H_NOT_FOUND);+returnEMULATE_DONE;+}++copy_to_user((void__user*)pteg,&v,sizeof(v));++rb=compute_tlbie_rb(pte[0],pte[1],pte_index);+vcpu->arch.mmu.tlbie(vcpu,rb,rb&1?true:false);++kvmppc_set_gpr(vcpu,3,H_SUCCESS);+kvmppc_set_gpr(vcpu,4,pte[0]);+kvmppc_set_gpr(vcpu,5,pte[1]);++returnEMULATE_DONE;+}++staticintkvmppc_h_pr_protect(structkvm_vcpu*vcpu)+{+unsignedlongflags=kvmppc_get_gpr(vcpu,4);+unsignedlongpte_index=kvmppc_get_gpr(vcpu,5);+unsignedlongavpn=kvmppc_get_gpr(vcpu,6);+unsignedlongrb,pteg,r,v;+unsignedlongpte[2];++pteg=get_pteg_addr(vcpu,pte_index);+copy_from_user(pte,(void__user*)pteg,sizeof(pte));++if((pte[0]&HPTE_V_VALID)==0||+((flags&H_AVPN)&&(pte[0]&~0x7fUL)!=avpn)){+kvmppc_set_gpr(vcpu,3,H_NOT_FOUND);+returnEMULATE_DONE;+}++v=pte[0];+r=pte[1];+r&=~(HPTE_R_PP0|HPTE_R_PP|HPTE_R_N|HPTE_R_KEY_HI|+HPTE_R_KEY_LO);+r|=(flags<<55)&HPTE_R_PP0;+r|=(flags<<48)&HPTE_R_KEY_HI;+r|=flags&(HPTE_R_PP|HPTE_R_N|HPTE_R_KEY_LO);++pte[1]=r;++rb=compute_tlbie_rb(v,r,pte_index);+vcpu->arch.mmu.tlbie(vcpu,rb,rb&1?true:false);+copy_to_user((void__user*)pteg,pte,sizeof(pte));++kvmppc_set_gpr(vcpu,3,H_SUCCESS);++returnEMULATE_DONE;+}++intkvmppc_h_pr(structkvm_vcpu*vcpu,unsignedlongcmd)+{+switch(cmd){+caseH_ENTER:+returnkvmppc_h_pr_enter(vcpu);+caseH_REMOVE:+returnkvmppc_h_pr_remove(vcpu);+caseH_PROTECT:+returnkvmppc_h_pr_protect(vcpu);+caseH_BULK_REMOVE:+/* We just flush all PTEs, so user space can+handletheHPTmodifications*/+kvmppc_mmu_pte_flush(vcpu,0,0);+break;+caseH_CEDE:+kvm_vcpu_block(vcpu);+vcpu->stat.halt_wakeup++;+returnEMULATE_DONE;+}++returnEMULATE_FAIL;+}
From: Alexander Graf <hidden> Date: 2011-08-09 16:32:00
Until 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.
Signed-off-by: Alexander Graf <redacted>
---
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(-)
@@ -90,6 +90,8 @@ struct kvmppc_vcpu_book3s {#endifintcontext_id[SID_CONTEXTS];+boolhior_sregs;/* HIOR is set by SREGS, not PVR */+structhlist_headhpte_hash_pte[HPTEG_HASH_NUM_PTE];structhlist_headhpte_hash_pte_long[HPTEG_HASH_NUM_PTE_LONG];structhlist_headhpte_hash_vpte[HPTEG_HASH_NUM_VPTE];
@@ -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;+return0;}
@@ -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;+}+return0;}
From: Avi Kivity <hidden> Date: 2011-08-09 16:40:58
On 08/09/2011 07:31 PM, Alexander Graf wrote:
quoted hunk
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.
From: Avi Kivity <hidden> Date: 2011-08-09 16:42:55
On 08/09/2011 07:31 PM, Alexander Graf wrote:
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?
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.
--
error compiling committee.c: too many arguments to function
From: Alexander Graf <hidden> Date: 2011-08-09 16:46:42
On 08/09/2011 06:40 PM, Avi Kivity wrote:
On 08/09/2011 07:31 PM, Alexander Graf wrote:
quoted
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.
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?
From: Avi Kivity <hidden> Date: 2011-08-09 16:49:37
On 08/09/2011 07:46 PM, Alexander Graf wrote:
On 08/09/2011 06:40 PM, Avi Kivity wrote:
quoted
On 08/09/2011 07:31 PM, Alexander Graf wrote:
quoted
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.
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?
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.
--
error compiling committee.c: too many arguments to function
From: Alexander Graf <hidden> Date: 2011-08-09 16:49:41
On 08/09/2011 06:42 PM, Avi Kivity wrote:
On 08/09/2011 07:31 PM, Alexander Graf wrote:
quoted
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
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.
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
From: Alexander Graf <hidden> Date: 2011-08-09 16:52:01
On 08/09/2011 06:49 PM, Avi Kivity wrote:
On 08/09/2011 07:46 PM, Alexander Graf wrote:
quoted
On 08/09/2011 06:40 PM, Avi Kivity wrote:
quoted
On 08/09/2011 07:31 PM, Alexander Graf wrote:
quoted
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.
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?
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
From: Avi Kivity <hidden> Date: 2011-08-09 17:01:50
On 08/09/2011 07:51 PM, Alexander Graf wrote:
quoted
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!
I meant Paul's or Ben's *review*.
--
error compiling committee.c: too many arguments to function
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2011-08-09 22:10:04
On Tue, 2011-08-09 at 20:01 +0300, Avi Kivity wrote:
On 08/09/2011 07:51 PM, Alexander Graf wrote:
quoted
quoted
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!
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.
From: Paul Mackerras <hidden> Date: 2011-08-10 04:42:15
On Tue, Aug 09, 2011 at 06:31:48PM +0200, Alexander Graf wrote:
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.
From: Alexander Graf <hidden> Date: 2011-08-10 08:00:08
Am 10.08.2011 um 06:42 schrieb Paul Mackerras [off-list ref]:
On Tue, Aug 09, 2011 at 06:31:48PM +0200, Alexander Graf wrote:
=20
quoted
Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap a=
nd
quoted
enable it for all Book3S targets. Enabling that CAP switches KVM into PAP=
R
quoted
mode.
=20
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 th=
e 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 c=
hange PVR or enable PAPR. That could set a variable in the vcpu struct to in=
dicate that the config is ok. We could then check that on vcpu_run.
Alex
From: Paul Mackerras <hidden> Date: 2011-08-10 12:26:32
On Wed, Aug 10, 2011 at 09:59:41AM +0200, Alexander Graf wrote:
Am 10.08.2011 um 06:42 schrieb Paul Mackerras [off-list ref]:
quoted
On Tue, Aug 09, 2011 at 06:31:48PM +0200, Alexander Graf wrote:
quoted
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.
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.
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.
It's probably not worth worrying about it.
The rest of the series looks very nice.
Regards,
Paul.
From: Alexander Graf <hidden> Date: 2011-08-10 12:29:31
On 08/10/2011 02:26 PM, Paul Mackerras wrote:
On Wed, Aug 10, 2011 at 09:59:41AM +0200, Alexander Graf wrote:
quoted
Am 10.08.2011 um 06:42 schrieb Paul Mackerras[off-list ref]:
quoted
On Tue, Aug 09, 2011 at 06:31:48PM +0200, Alexander Graf wrote:
quoted
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.
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
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.
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
From: Alexander Graf <hidden> Date: 2011-08-10 12:31:35
There 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.
Signed-off-by: Alexander Graf <redacted>
---
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(-)
@@ -390,6 +390,8 @@ struct kvm_vcpu_arch {u8osi_needed;u8osi_enabled;u8papr_enabled;+u8sane;+u8cpu_type;u8hcall_needed;u32cpr0_cfgaddr;/* holds the last set cpr0_cfgaddr */
@@ -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*treatDCBZas32bytesstore*/vcpu->arch.hflags&=~BOOK3S_HFLAG_DCBZ32;
@@ -938,6 +942,12 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)#endifulongext_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;
@@ -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;+return0;}
@@ -95,6 +95,31 @@ int kvmppc_kvm_pv(struct kvm_vcpu *vcpu)returnr;}+intkvmppc_sanity_check(structkvm_vcpu*vcpu)+{+intr=false;++/* We have to know what CPU to virtualize */+if(!vcpu->arch.pvr)+gotoout;++/* PAPR only works with book3s_64 */+if((vcpu->arch.cpu_type!=KVM_CPU_3S_64)&&vcpu->arch.papr_enabled)+gotoout;++#ifdef CONFIG_KVM_BOOK3S_64_HV+/* HV KVM can only do PAPR mode for now */+if(!vcpu->arch.papr_enabled)+gotoout;+#endif++r=true;++out:+vcpu->arch.sane=r;+returnr?0:-EINVAL;+}+intkvmppc_emulate_mmio(structkvm_run*run,structkvm_vcpu*vcpu){enumemulation_resulter;
@@ -582,6 +607,9 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,break;}+if(!r)+r=kvmppc_sanity_check(vcpu);+returnr;}
From: David Gibson <hidden> Date: 2011-08-12 03:33:43
On Tue, Aug 09, 2011 at 06:31:47PM +0200, Alexander Graf wrote:
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.
--
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
From: David Gibson <hidden> Date: 2011-08-12 03:35:29
On Tue, Aug 09, 2011 at 06:31:45PM +0200, Alexander Graf wrote:
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.
--
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
From: Alexander Graf <hidden> Date: 2011-08-12 05:36:01
Am 12.08.2011 um 05:33 schrieb David Gibson [off-list ref]:
On Tue, Aug 09, 2011 at 06:31:47PM +0200, Alexander Graf wrote:
quoted
PAPR defines hypercalls as SC1 instructions. Using these, the guest modif=
ies
quoted
page tables and does other privileged operations that it wouldn't be allo=
wed
quoted
to do in supervisor mode.
=20
This patch adds support for PR KVM to trap these instructions and route t=
hem
quoted
through the same PAPR hypercall interface that we already use for HV styl=
e
quoted
KVM.
=20
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.
=20
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
From: Alexander Graf <hidden> Date: 2011-08-12 05:39:13
Am 12.08.2011 um 05:35 schrieb David Gibson [off-list ref]:
On Tue, Aug 09, 2011 at 06:31:45PM +0200, Alexander Graf wrote:
quoted
When running a PAPR guest, we need to handle a few hypercalls in kernel s=
pace,
quoted
most prominently the page table invalidation (to sync the shadows).
=20
So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I t=
ried
quoted
to share the code with HV mode, but it ended up being a lot easier this w=
ay
quoted
around, as the two differ too much in those details.
=20
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.
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 h=
andle it in kvm as well :). Removal definitely needs to happin in-kernel.
Alex
From: David Gibson <hidden> Date: 2011-08-12 07:43:08
On Fri, Aug 12, 2011 at 07:38:54AM +0200, Alexander Graf wrote:
Am 12.08.2011 um 05:35 schrieb David Gibson [off-list ref]:
quoted
On Tue, Aug 09, 2011 at 06:31:45PM +0200, Alexander Graf wrote:
quoted
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.
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.
True. I think you could actually delay this invalidation until the
guest issues the tlbie, but it's probably not worth it.
--
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
From: David Gibson <hidden> Date: 2011-08-12 07:43:59
On Fri, Aug 12, 2011 at 07:35:42AM +0200, Alexander Graf wrote:
Am 12.08.2011 um 05:33 schrieb David Gibson [off-list ref]:
quoted
On Tue, Aug 09, 2011 at 06:31:47PM +0200, Alexander Graf wrote:
quoted
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.
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.
But yes, PHyP guests can't
run this target yet :). I'll take a stab at that too, but one
continent at a time! ;)
--
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
From: Alexander Graf <hidden> Date: 2011-08-12 08:07:47
Am 12.08.2011 um 09:43 schrieb David Gibson [off-list ref]:
On Fri, Aug 12, 2011 at 07:35:42AM +0200, Alexander Graf wrote:
quoted
=20
Am 12.08.2011 um 05:33 schrieb David Gibson [off-list ref]=
:
quoted
=20
quoted
On Tue, Aug 09, 2011 at 06:31:47PM +0200, Alexander Graf wrote:
quoted
PAPR defines hypercalls as SC1 instructions. Using these, the guest mod=
ifies
quoted
quoted
quoted
page tables and does other privileged operations that it wouldn't be al=
lowed
quoted
quoted
quoted
to do in supervisor mode.
=20
This patch adds support for PR KVM to trap these instructions and route=
them
quoted
quoted
quoted
through the same PAPR hypercall interface that we already use for HV st=
yle
quoted
quoted
quoted
KVM.
=20
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.
=20
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.
=20
Well I'd like to keep Qemu out of the patching business, so the
guest kernel would have to patch itself.
=20
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 kerne=
l 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 m=
eans we need to patch the guest from the outside :). If you really need to u=
se 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 ru=
n on broken hypervisors.
Alex
From: Alexander Graf <hidden> Date: 2011-08-12 08:09:18
Am 12.08.2011 um 09:43 schrieb David Gibson [off-list ref]:
On Fri, Aug 12, 2011 at 07:38:54AM +0200, Alexander Graf wrote:
quoted
=20
Am 12.08.2011 um 05:35 schrieb David Gibson [off-list ref]=
:
quoted
=20
quoted
On Tue, Aug 09, 2011 at 06:31:45PM +0200, Alexander Graf wrote:
quoted
When running a PAPR guest, we need to handle a few hypercalls in kernel=
space,
quoted
quoted
quoted
most prominently the page table invalidation (to sync the shadows).
=20
So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I=
tried
quoted
quoted
quoted
to share the code with HV mode, but it ended up being a lot easier this=
way
quoted
quoted
quoted
around, as the two differ too much in those details.
=20
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.
=20
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.
=20
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=
From: Andreas Schwab <hidden> Date: 2011-11-08 17:09:05
compute_tlbie_rb is only used on ppc64 and cannot be compiled on ppc32.
Signed-off-by: Andreas Schwab <redacted>
---
arch/powerpc/include/asm/kvm_book3s.h | 33 ------------------------------
arch/powerpc/include/asm/kvm_book3s_64.h | 33 ++++++++++++++++++++++++++++++
2 files changed, 33 insertions(+), 33 deletions(-)
@@ -383,39 +383,6 @@ static inline bool kvmppc_critical_section(struct kvm_vcpu *vcpu)}#endif-staticinlineunsignedlongcompute_tlbie_rb(unsignedlongv,unsignedlongr,-unsignedlongpte_index)-{-unsignedlongrb,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 */-returnrb;-}-/* Magic register values loaded into r3 and r4 before the 'sc' assembly*instructionfortheOSIhypercalls*/#define OSI_SC_MAGIC_R3 0x113724FA
@@ -29,4 +29,37 @@ static inline struct kvmppc_book3s_shadow_vcpu *to_svcpu(struct kvm_vcpu *vcpu)#define SPAPR_TCE_SHIFT 12+staticinlineunsignedlongcompute_tlbie_rb(unsignedlongv,unsignedlongr,+unsignedlongpte_index)+{+unsignedlongrb,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 */+returnrb;+}+#endif /* __ASM_KVM_BOOK3S_64_H__ */
--
1.7.7.2
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
From: Andreas Schwab <hidden> Date: 2011-11-08 17:17:41
kvmppc_h_pr is only available if CONFIG_KVM_BOOK3S_64_PR.
Signed-off-by: Andreas Schwab <redacted>
---
arch/powerpc/kvm/book3s_pr.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)