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? > >> 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" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
