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

[Hollis Blanchard <hollisb@us.ibm.com>]

On Thu, 2008-01-24 at 08:23 +0100, Christian Ehrhardt wrote:
> 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 ;-)

I like it that way. :)

Also, we will need a "TLB specifier" argument for e500, to differentiate
between TLB0 and TLB1.

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

Yeah, you're right... if it were just WIMG I don't think we'd have a
problem, but we also have permissions to worry about. In addition, not
all processors support non-executable mappings. I'm starting to think a
little bit of processor-specific code in userspace wouldn't be such a
bad thing, and maybe we should just give up on this "generic" idea
entirely.

-- 
Hollis Blanchard
IBM Linux Technology Center


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