From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Ehrhardt Date: Thu, 24 Jan 2008 07:23:42 +0000 Subject: Re: [kvm-ppc-devel] KVM kernel/userspace TLB interface Message-Id: <47983CFE.3070000@linux.vnet.ibm.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: kvm-ppc@vger.kernel.org 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). >=20 > 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 =3D>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 ch= ange 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 nee= d 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 exp= licitly ;-) >> 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). >=20 > "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 rw= x@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 c= an compare it to our needs. --=20 Gr=FCsse / regards,=20 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