> -----Original Message----- > From: Alexander Graf [mailto:ag...@suse.de] > Sent: Thursday, March 21, 2013 1:07 PM > To: Caraman Mihai Claudiu-B02008 > Cc: Wood Scott-B07421; kvm-...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; k...@vger.kernel.org > Subject: Re: [PATCH] KVM: PPC: e500: Expose MMU registers via ONE_REG > > > On 21.03.2013, at 12:02, Caraman Mihai Claudiu-B02008 wrote: > > > > > > >> -----Original Message----- > >> From: Alexander Graf [mailto:ag...@suse.de] > >> Sent: Thursday, March 21, 2013 12:07 PM > >> To: Wood Scott-B07421 > >> Cc: Caraman Mihai Claudiu-B02008; kvm-...@vger.kernel.org; linuxppc- > >> d...@lists.ozlabs.org; k...@vger.kernel.org > >> Subject: Re: [PATCH] KVM: PPC: e500: Expose MMU registers via ONE_REG > >> > >> > >> On 19.03.2013, at 18:26, Scott Wood wrote: > >> > >>> On 03/19/2013 12:17:11 PM, Mihai Caraman wrote: > >>>> diff --git a/arch/powerpc/kvm/e500_mmu.c > b/arch/powerpc/kvm/e500_mmu.c > >>>> index 66b6e31..b77b855 100644 > >>>> --- a/arch/powerpc/kvm/e500_mmu.c > >>>> +++ b/arch/powerpc/kvm/e500_mmu.c > >>>> @@ -596,6 +596,95 @@ int kvmppc_set_sregs_e500_tlb(struct kvm_vcpu > >> *vcpu, struct kvm_sregs *sregs) > >>>> return 0; > >>>> } > >>>> +int kvmppc_get_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id, > >>>> + union kvmppc_one_reg *val) > >>> > >>> s/500/e500/ > >>> > >>>> +int kvmppc_set_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id, > >>>> + union kvmppc_one_reg *val) > >>>> +{ > >>>> + int r = 0; > >>>> + long int i; > >>>> + > >>>> + switch (id) { > >>>> + case KVM_REG_PPC_MAS0: > >>>> + vcpu->arch.shared->mas0 = set_reg_val(id, *val); > >>>> + break; > >>>> + case KVM_REG_PPC_MAS1: > >>>> + vcpu->arch.shared->mas1 = set_reg_val(id, *val); > >>>> + break; > >>>> + case KVM_REG_PPC_MAS2: > >>>> + vcpu->arch.shared->mas2 = set_reg_val(id, *val); > >>>> + break; > >>>> + case KVM_REG_PPC_MAS7_3: > >>>> + vcpu->arch.shared->mas7_3 = set_reg_val(id, *val); > >>>> + break; > >>>> + case KVM_REG_PPC_MAS4: > >>>> + vcpu->arch.shared->mas4 = set_reg_val(id, *val); > >>>> + break; > >>>> + case KVM_REG_PPC_MAS6: > >>>> + vcpu->arch.shared->mas6 = set_reg_val(id, *val); > >>>> + break; > >>>> + case KVM_REG_PPC_MMUCFG: { > >>>> + u32 mmucfg = set_reg_val(id, *val); > >>>> + vcpu->arch.mmucfg = mmucfg & ~MMUCFG_LPIDSIZE; > >>>> + break; > >>>> + } > >>> > >>> Do we really want to allow arbitrary MMUCFG changes? It won't > >> magically make us able to support larger RAs, PIDs, different MAVN, > etc. > > > > Not magically, some changes e.g TLBnCFG_IND or TLBnPS require just a > kvm > > check other changes e.g. TLBnCFG_MAVN require additional support and we > > might not implement all of them. Until then this code should do the > job: > > > > /* MMU registers can be set only to the configuration supported by > KVM */ > > case KVM_REG_PPC_MMUCFG: { > > if (set_reg_val(id, *val) != vcpu->arch.mmucfg) > > r = -EINVAL; > > break; > > } > > Yes :). > > > > >> > >> Only if we update the actual shadow mmu configuration as well. > > > > These registers (MMUCFG, EPTCFG, TLBnCFG, TLBnPS) are read-only (and > shared > > between e6500 threads), we can only emulate them. > > We need to change the behavior of the shadow mmu as well. It's not about > the registers, but the actually exposed TLBs. If you configure 4 TLBs, > and you announce to the guest that you can do 4 TLBs, you better emulate > 4 TLBs :).
Right, like the rest of configs I was talking above:) -Mike _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
