[PATCH] KVM: PPC: e500: Expose MMU registers via ONE_REG

[Caraman Mihai Claudiu-B02008]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf at suse.de]
> Sent: Thursday, March 21, 2013 1:07 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: Wood Scott-B07421; kvm-ppc at vger.kernel.org; linuxppc-
> dev at lists.ozlabs.org; kvm at 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:agraf at suse.de]
> >> Sent: Thursday, March 21, 2013 12:07 PM
> >> To: Wood Scott-B07421
> >> Cc: Caraman Mihai Claudiu-B02008; kvm-ppc at vger.kernel.org; linuxppc-
> >> dev at lists.ozlabs.org; kvm at 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