diff mbox

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

Message ID 1340627195-11544-6-git-send-email-mihai.caraman@freescale.com
State New, archived
Headers show

Commit Message

Mihai Caraman June 25, 2012, 12:26 p.m. UTC
Extend MAS2 EPN mask for 64-bit hosts, to retain most significant bits.
Change get tlb eaddr to use this mask.

Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
---
 arch/powerpc/include/asm/mmu-book3e.h |    2 +-
 arch/powerpc/kvm/e500.h               |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Comments

Alexander Graf July 4, 2012, 1:49 p.m. UTC | #1
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.
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.


Alex

--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Caraman Mihai Claudiu-B02008 July 5, 2012, 11:14 a.m. UTC | #2
> -----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
> 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.

> 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?

Freescale core Manuals and EREF does not mention MAS2U so I think I our case
it is not implemented.

-Mike


--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Alexander Graf Oct. 8, 2012, 10:10 a.m. UTC | #3
On 05.07.2012, at 13:14, Caraman Mihai Claudiu-B02008 wrote:

> 
> 
>> -----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
>> 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?

> 
>> 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?

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


Alex

--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Caraman Mihai Claudiu-B02008 Oct. 8, 2012, 1:06 p.m. UTC | #4
> -----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
> EPN mask for 64-bit
> 
> 
> On 05.07.2012, at 13:14, Caraman Mihai Claudiu-B02008 wrote:
> 
> >
> >
> >> -----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
> >> 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.

> 
> >
> >> 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?

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

-Mike




--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Alexander Graf Oct. 8, 2012, 1:10 p.m. UTC | #5
On 08.10.2012, at 15:06, Caraman Mihai Claudiu-B02008 wrote:

>> -----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
>> EPN mask for 64-bit
>> 
>> 
>> On 05.07.2012, at 13:14, Caraman Mihai Claudiu-B02008 wrote:
>> 
>>> 
>>> 
>>>> -----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
>>>> 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

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

Patch

diff --git a/arch/powerpc/include/asm/mmu-book3e.h b/arch/powerpc/include/asm/mmu-book3e.h
index eeabcdb..99d43e0 100644
--- a/arch/powerpc/include/asm/mmu-book3e.h
+++ b/arch/powerpc/include/asm/mmu-book3e.h
@@ -59,7 +59,7 @@ 
 #define MAS1_TSIZE_SHIFT	7
 #define MAS1_TSIZE(x)		(((x) << MAS1_TSIZE_SHIFT) & MAS1_TSIZE_MASK)
 
-#define MAS2_EPN		0xFFFFF000
+#define MAS2_EPN		(~0xFFFUL)
 #define MAS2_X0			0x00000040
 #define MAS2_X1			0x00000020
 #define MAS2_W			0x00000010
diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.h
index aa8b814..3e31098 100644
--- a/arch/powerpc/kvm/e500.h
+++ b/arch/powerpc/kvm/e500.h
@@ -155,7 +155,7 @@  get_tlb_size(const struct kvm_book3e_206_tlb_entry *tlbe)
 
 static inline gva_t get_tlb_eaddr(const struct kvm_book3e_206_tlb_entry *tlbe)
 {
-	return tlbe->mas2 & 0xfffff000;
+	return tlbe->mas2 & MAS2_EPN;
 }
 
 static inline u64 get_tlb_bytes(const struct kvm_book3e_206_tlb_entry *tlbe)