From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Date: Thu, 24 Jan 2008 07:37:21 +0000 Subject: Re: [kvm-ppc-devel] KVM kernel/userspace TLB interface Message-Id: <1201160242.25840.21.camel@basalt> List-Id: References: <1199751688.5741.40.camel@basalt> In-Reply-To: <1199751688.5741.40.camel@basalt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-ppc@vger.kernel.org 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