Re: [PATCH 0/2] kvm/e500v2: MMU optimization

[Hollis Blanchard <hollis_blanchard-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>]

On 09/09/2010 04:03 AM, Liu Yu-B13201 wrote:
>> -----Original Message-----
>> From: kvm-ppc-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> [mailto:kvm-ppc-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Hollis Blanchard
>> Sent: Thursday, September 09, 2010 12:07 AM
>> To: Liu Yu-B13201
>> Cc: kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; agraf-l3A5Bk7waGM@public.gmane.org
>> Subject: Re: [PATCH 0/2] kvm/e500v2: MMU optimization
>>
>> On 09/08/2010 02:40 AM, Liu Yu wrote:
>>      
>>> The patchset aims at mapping guest TLB1 to host TLB0.
>>> And it includes:
>>> [PATCH 1/2] kvm/e500v2: Remove shadow tlb
>>> [PATCH 2/2] kvm/e500v2: mapping guest TLB1 to host TLB0
>>>
>>> The reason we need patch 1 is because patch 1 make things
>>>        
>> simple and flexible.
>>      
>>> Only applying patch 1 aslo make kvm work.
>>>        
>> I've always thought the best long-term "optimization" on
>> these cores is
>> to share in the host PID allocation (i.e. __init_new_context()). This
>> way, the TID in guest mappings would not overlap the TID in host
>> mappings, and guest mappings could be demand-faulted rather
>> than swapped
>> wholesale. To do that, you would need to track the host PID
>> in KVM data
>> structures, I guess in the tlbe_ref structure.
>>
>>      
> Hi Hollis,
>
> Guest uses AS=1 and host uses AS=0,
> so even guest uses the same TID with host, they're in different space.
>
> Then why guest needs to care about host TID?
>
>    
You're absolutely right, but this makes a couple key assumptions:
1. The guest doesn't try to use AS=1. This is already false in Linux, 
because the udbg code uses an AS=1 mapping for the UART, but this can be 
configured out (with a small loss in functionality). In non-Linux guests 
the AS=0 restriction could be onerous.
2. A Book E MMU. If we participate in the host "MMU context" allocation, 
the guest -> host address space code could be generalized to include 
e.g. an e600 guest on an e500 host, or vice versa.

So you're right that "optimization" is not the right word; this would be 
more of a functionality and design improvement. (In fact, I suppose it 
could reduce performance on Book E, since AS=1 space actually *is* 
unused by the host. I think it would be worth finding out.)

Hollis Blanchard
Mentor Graphics, Embedded Systems Division