[Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend MAS2 EPN mask for 64-bit

[Alexander Graf]

On 08.10.2012, at 15:06, Caraman Mihai Claudiu-B02008 wrote:

>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf at suse.de]
>> Sent: Monday, October 08, 2012 1:11 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: kvm-ppc at vger.kernel.org; kvm at vger.kernel.org; linuxppc-
>> dev at lists.ozlabs.org; qemu-ppc at nongnu.org
>> Subject: Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend MAS2
>> EPN mask for 64-bit
>> 
>> 
>> On 05.07.2012, at 13:14, Caraman Mihai Claudiu-B02008 wrote:
>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Alexander Graf [mailto:agraf at suse.de]
>>>> Sent: Wednesday, July 04, 2012 4:50 PM
>>>> To: Caraman Mihai Claudiu-B02008
>>>> Cc: kvm-ppc at vger.kernel.org; kvm at vger.kernel.org; linuxppc-
>>>> dev at lists.ozlabs.org; qemu-ppc at nongnu.org
>>>> Subject: Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend MAS2
>>>> EPN mask for 64-bit
>>>> 
>>>> 
>>>> On 25.06.2012, at 14:26, Mihai Caraman wrote:
>>>> 
>>>>> Extend MAS2 EPN mask for 64-bit hosts, to retain most significant
>> bits.
>>>>> Change get tlb eaddr to use this mask.
>>>> 
>>>> Please see section 6.11.4.8 in the PowerISA 2.06b:
>>>> 
>>>> MMU behavior is largely unaffected by whether the thread is in 32-bit
>>>> computation mode (MSRCM=0) or 64- bit computation mode (MSRCM=1). The
>>>> only differ- ences occur in the EPN field of the TLB entry and the EPN
>>>> field of MAS2. The differences are summarized here.
>>>> 
>>>> 	*  Executing a tlbwe instruction in 32-bit mode will set bits 0:31
>>>> of the TLB EPN field to zero unless MAS0ATSEL is set, in which case
>> those
>>>> bits are not written to zero.
>>>> 	*  In 32-bit implementations, MAS2U can be used to read or write
>>>> EPN0:31 of MAS2.
>>>> 
>>>> So if MSR.CM is not set tlbwe should mask the upper 32 bits out -
>> which
>>>> can happen regardless of CONFIG_64BIT.
>>> 
>>> MAS2_EPN reflects EPN field of MAS2 aka bits 0:51 (for MAV = 1.0)
>> according
>>> to section 6.10.3.10 in the PowerISA 2.06b.
>>> 
>>> MAS2_EPN is not used in tlbwe execution emulation, we have MAS2_VAL
>> define
>>> for this case.
>> 
>> So tlbe->mas2 is guaranteed to have the upper bits be 0 when MSR.CM=0?
> 
> We chose to mask out mas2 upper bits on tlbwe emulation so gtlbe->mas2 will
> respect this but vcpu->arch.shared->mas2 will not. tlb entry selection does not
> require this treatment since EPN upper bits are not taken into consideration anyway.

That's fine. We don't control the contents of shared->mas2 anyway.

> 
>> 
>>> 
>>>> Also, we need to implement MAS2U, to potentially make the upper 32bits
>> of
>>>> MAS2 available, right? But that one isn't as important as the first
>> bit.
>>> 
>>> MAS2U is guest privileged why does it need special care?
>> 
>> Maybe it's mapped to the upper bits of GMAS2 automatically?
> 
> GMAS2?

Ah. The guest has direct control over the real MAS2. Oh well.

> 
>> 
>>> Freescale core Manuals and EREF does not mention MAS2U so I think I our
>> case
>>> it is not implemented.
>> 
>> Please check with a simple mfspr() test on real hw to see if it really
>> isn't implemented.
> 
> I will try this with SPR number 0x277.

Thanks :)


Alex