Re: [kvm-ppc-devel] KVM kernel/userspace TLB interface

[Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>]

Hollis Blanchard wrote:
> On Wed, 2008-01-23 at 14:38 +0100, Christian Ehrhardt wrote:
>> Christian Ehrhardt wrote:
>>
>> This mail now has the reworked implementation of the patch for ppc440
>> in the #2 style attached where the guest tlb can be get/set completely
>> and the shadow tlb can be read from userspace (now separate ioctls for
>> guest/shadow).
> 
> I don't think the host userspace should ever need to directly manipulate
> the shadow TLB state. IIRC x86 just has a "sync shadow MMU state"
> command (not sure what it does or when you use it though).

I agree and the patch has only
KVM_GET_GUEST_TLB
KVM_SET_GUEST_TLB
KVM_GET_SHADOW_TLB
=>no manipulation to the shadow TLB possible.

> I also really don't like accessing the whole TLB as a giant array when
> single-entry commands would work just fine.

Well I think it is just easier to do it with the full array. Its easy to change that to a 1xtlbe+1xindex interface that can be iterated by userspace, but I don't see any benefit atm.
Code where we set up the TLB are not performance relevant so a big array as well as iterating with a lot of calls are both not hurting us. If we think of the get/set as interface used for dump tlb and save/restore we will need to access the full array anyway.
So if you want it as single tlbe get/set is there a specific argument ? The argument "do it because I like it that way" is also accepted if stated explicitly ;-)

>> Actually this should work for most if not all use cases we have.
>> Especially our current use case of setting up a proper initial state
>> is very arch dependent anyway and if we really can save userspace code
>> for shared usage depends on the fact if we will be able to create a
>> shared bit format for flags (I start to put a common "map this" call
>> down on my prio list).
> 
> "Flags" could just indicate IO vs RAM mappings. That would be nice and
> generic. If IO flag is set, the host would map with
> cache-inhibited/guarded. If not, it's a RAM mapping, so don't.

I would hope it is so an easy flagging. Don't you think we need all that rwx@problem/kernel state (well both have that) and e.g. e500 needs something more than we are because they are supporting the M flag ("Memory Coherency required"). Well maybe all becomes clear when we see Zhang Wei's code and can compare it to our needs.


-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel