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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux