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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 21.03.2013, at 12:02, Caraman Mihai Claudiu-B02008 wrote:

> 
> 
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@xxxxxxx]
>> Sent: Thursday, March 21, 2013 12:07 PM
>> To: Wood Scott-B07421
>> Cc: Caraman Mihai Claudiu-B02008; kvm-ppc@xxxxxxxxxxxxxxx; linuxppc-
>> dev@xxxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx
>> 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 :).


Alex

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux