From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KIn8z-0003Oj-1e for qemu-devel@nongnu.org; Tue, 15 Jul 2008 12:12:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KIn8u-0003MH-7w for qemu-devel@nongnu.org; Tue, 15 Jul 2008 12:12:48 -0400 Received: from [199.232.76.173] (port=42717 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KIn8u-0003MA-2b for qemu-devel@nongnu.org; Tue, 15 Jul 2008 12:12:44 -0400 Received: from mail2.shareable.org ([80.68.89.115]:58876) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KIn8t-0006bW-OC for qemu-devel@nongnu.org; Tue, 15 Jul 2008 12:12:44 -0400 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1KIn8q-00008C-S3 for qemu-devel@nongnu.org; Tue, 15 Jul 2008 17:12:40 +0100 Date: Tue, 15 Jul 2008 17:12:40 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [RFC][PATCH] x86: Optional segment type and limit checks - v2 Message-ID: <20080715161240.GA32365@shareable.org> References: <4874AB47.9090208@siemens.com> <487B2BC8.9050804@siemens.com> <20080714105531.GB2381@shareable.org> <200807141211.49825.paul@codesourcery.com> <20080714140238.GA5496@shareable.org> <20080714175027.GA6719@morn.localdomain> <20080714185147.GA12436@shareable.org> <487CC6C7.3090408@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <487CC6C7.3090408@siemens.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Jan Kiszka wrote: > Don't want to stop all your creativity, but just like Paul I'm also a > bit skeptical about the TLB way of achieving range and type safety. Sure, that's understandable. There has to be some "show me the code" - I wish I had the time. These are not simple optimisations, but they could make segment checks free for most guests, so it's worth considering them even if they're discarded. > My major concern once was that the TLB works on a global scope so that > you cannot tell the original segments behind some address apart. Yes. The only way around it is context - either having multiple TLBs, or inlining segments into translated code, so you tell the original segments apart at the call site. > And extending the virtual address space for this is a no-go on > 32-bit hosts (which I unfortunately had and still have to support > here :->). Definitely not increasing the virtual address space - I'm still using 32-bit hosts too :-) I'm not sure that would be safe even on 64-bit hosts - what if the guest has its own uses for the whole address space? Expanding the TLB key space (or equivalently, multiple TLBs) is different from expanding the virtual address space, though. -- Jamie