On 08.10.2012, at 15:06, Caraman Mihai Claudiu-B02008 wrote: >> -----Original Message----- >> From: Alexander Graf [mailto:ag...@suse.de] >> Sent: Monday, October 08, 2012 1:11 PM >> To: Caraman Mihai Claudiu-B02008 >> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc- >> d...@lists.ozlabs.org; qemu-...@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:ag...@suse.de] >>>> Sent: Wednesday, July 04, 2012 4:50 PM >>>> To: Caraman Mihai Claudiu-B02008 >>>> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc- >>>> d...@lists.ozlabs.org; qemu-...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
