> -----Original Message----- > From: Alexander Graf [mailto:agraf@xxxxxxx] > Sent: Monday, October 08, 2012 1:11 PM > To: Caraman Mihai Claudiu-B02008 > Cc: kvm-ppc@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; linuxppc- > dev@xxxxxxxxxxxxxxxx; qemu-ppc@xxxxxxxxxx > 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@xxxxxxx] > >> Sent: Wednesday, July 04, 2012 4:50 PM > >> To: Caraman Mihai Claudiu-B02008 > >> Cc: kvm-ppc@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; linuxppc- > >> dev@xxxxxxxxxxxxxxxx; qemu-ppc@xxxxxxxxxx > >> 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" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
