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

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

quoted

-----Original Message-----
From: Alexander Graf [mailto:agraf@suse.de]
Sent: Monday, October 08, 2012 1:11 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
dev@lists.ozlabs.org; qemu-ppc@nongnu.org
Subject: Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend =

MAS2

quoted

EPN mask for 64-bit
=20
=20
On 05.07.2012, at 13:14, Caraman Mihai Claudiu-B02008 wrote:
=20

quoted

=20
=20

quoted

-----Original Message-----
From: Alexander Graf [mailto:agraf@suse.de]
Sent: Wednesday, July 04, 2012 4:50 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
dev@lists.ozlabs.org; qemu-ppc@nongnu.org
Subject: Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend =

MAS2

quoted

quoted

quoted

EPN mask for 64-bit
=20
=20
On 25.06.2012, at 14:26, Mihai Caraman wrote:
=20

quoted

Extend MAS2 EPN mask for 64-bit hosts, to retain most significant

bits.

quoted

quoted

quoted

Change get tlb eaddr to use this mask.

=20
Please see section 6.11.4.8 in the PowerISA 2.06b:
=20
MMU behavior is largely unaffected by whether the thread is in =

32-bit

quoted

quoted

quoted

computation mode (MSRCM=3D0) or 64- bit computation mode (MSRCM=3D1).=

 The

quoted

quoted

quoted

only differ- ences occur in the EPN field of the TLB entry and the =

EPN

quoted

quoted

quoted

field of MAS2. The differences are summarized here.
=20
	*  Executing a tlbwe instruction in 32-bit mode will set bits =

0:31

quoted

quoted

quoted

of the TLB EPN field to zero unless MAS0ATSEL is set, in which case

those

quoted

quoted

bits are not written to zero.
	*  In 32-bit implementations, MAS2U can be used to read or write
EPN0:31 of MAS2.
=20
So if MSR.CM is not set tlbwe should mask the upper 32 bits out -

which

quoted

quoted

can happen regardless of CONFIG_64BIT.

=20
MAS2_EPN reflects EPN field of MAS2 aka bits 0:51 (for MAV =3D 1.0)

according

quoted

to section 6.10.3.10 in the PowerISA 2.06b.
=20
MAS2_EPN is not used in tlbwe execution emulation, we have MAS2_VAL

define

quoted

for this case.

=20
So tlbe->mas2 is guaranteed to have the upper bits be 0 when =

MSR.CM=3D0?

=20
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.

=20

quoted

=20

quoted

=20

quoted

Also, we need to implement MAS2U, to potentially make the upper =

32bits

quoted

of

quoted

quoted

MAS2 available, right? But that one isn't as important as the first

bit.

quoted

=20
MAS2U is guest privileged why does it need special care?

=20
Maybe it's mapped to the upper bits of GMAS2 automatically?

=20
GMAS2?

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

=20

quoted

=20

quoted

Freescale core Manuals and EREF does not mention MAS2U so I think I =

our

quoted

case

quoted

it is not implemented.

=20
Please check with a simple mfspr() test on real hw to see if it =

really

quoted

isn't implemented.

=20
I will try this with SPR number 0x277.

Thanks :)


Alex