[PATCH][RFC] Replaced tlbilx with tlbwe in the initialization code

[Scott Wood]

On 02/15/2013 09:16:15 AM, Diana Craciun wrote:
> On 02/15/2013 02:11 AM, Benjamin Herrenschmidt wrote:
>> On Thu, 2013-02-14 at 14:56 +0200, Diana Craciun wrote:
>>> From: Diana Craciun <Diana.Craciun at freescale.com>
>>> 
>>> On Freescale e6500 cores EPCR[DGTMI] controls whether guest  
>>> supervisor
>>> state can execute TLB management instructions. If EPCR[DGTMI]=0
>>> tlbwe and tlbilx are allowed to execute normally in the guest state.
>>> 
>>> A hypervisor may choose to virtualize TLB1 and for this purpose it
>>> may use IPROT to protect the entries for being invalidated by the
>>> guest. However, because tlbwe and tlbilx execution in the guest  
>>> state
>>> are sharing the same bit, it is not possible to have a scenario  
>>> where
>>> tlbwe is allowed to be executed in guest state and tlbilx traps.  
>>> When
>>> guest TLB management instructions are allowed to be executed in  
>>> guest
>>> state the guest cannot use tlbilx to invalidate TLB1 guest entries.
>> Sorry, I don't understand the explanation... can you be more  
>> detailed ?
> 
> TLB1 supports huge page sizes. The guest may see the memory as  
> contiguous but it sees the guest physical memory as presented by the  
> hypervisor. In reality the real physical memory may be fragmented. In  
> this case the hypervisor can add more than one TLB1 entry for one  
> guest request and the hypervisor will keep track of all fragments.  
> When the guest performs a tlbilx, the hypervisor will correctly  
> invalidate all the corresponding fragments because both tlbwe and  
> tlbilx trap and has full control of tlb management instructions  
> targeting TLB1.
> 
> For e6500 a single bit controls if tlbwe and tlbilx trap to the  
> Hypervisor. tlbwe targeting TLB1 always traps. But if we want to use  
> LRAT for TLB0, we have to configure tlbwe (targeting TLB 0) to go  
> directly to the guest. But in this case tlbilx (which is targeting  
> both TLBs) will never trap.
> 
> If the tlbilx does not trap, the guest can invalidate only one of  
> (possible more) fragments and furthermore the synchronization between  
> what entries the hypervisor thinks there are in the TLB1 and what are  
> the actual entries is lost.

This patch addresses boot-time invalidations only.  How will you handle  
hugetlb invalidations (or indirect entry invalidations, once that  
becomes supported)?

-Scott