From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KJU7z-00039P-Bv for qemu-devel@nongnu.org; Thu, 17 Jul 2008 10:06:39 -0400 Received: from [199.232.76.173] (port=59217 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KJU7y-00039E-HI for qemu-devel@nongnu.org; Thu, 17 Jul 2008 10:06:38 -0400 Received: from mx1.polytechnique.org ([129.104.30.34]:53118) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KJU7y-00020V-16 for qemu-devel@nongnu.org; Thu, 17 Jul 2008 10:06:38 -0400 Received: from fbe1.dev.netgem.com (gw.netgem.com [195.68.2.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTP id 2849133170 for ; Thu, 17 Jul 2008 16:06:26 +0200 (CEST) Message-ID: <487F51E1.9070102@bellard.org> Date: Thu, 17 Jul 2008 16:06:25 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC][PATCH] x86: CS limit checks References: <487F3393.3040609@siemens.com> In-Reply-To: <487F3393.3040609@siemens.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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: > Here is a proposal for adding code segment limit checks to x86. This > patch should not need the -seg-checks switch as its tests are mostly > performed during translation time. Moreover, I tried to confine the > small additional overhead in the TB lookup procedure to x86 and Sparc. > > Note that this patch depends on my debugging series, namely [1], as that > one reduces the x86-specific code passages for TB generation. Also note > that this patch is early and only lightly tested so far, not yet > intended for inclusion, but definitely for commenting on! Using more than 32 bits for cs_limit (and cs_base) in the TB is wasteful, so I strongly suggest to use a uint32_t type. In that case, cs_limit must be explicitely ignored in 64 bit code. @@ -172,6 +173,8 @@ static inline TranslationBlock *tb_find_ flags = env->hflags; flags |= (env->eflags & (IOPL_MASK | TF_MASK | VM_MASK)); cs_base = env->segs[R_CS].base; + if ((env->hflags & (HF_PE_MASK | HF_CS64_MASK)) == HF_PE_MASK) + cs_limit = env->segs[R_CS].limit; pc = cs_base + env->eip; This test should be suppressed for performance reasons. Generally speaking as I said in a private mail, I don't want an option -seg-checks: the segment limit and right checks must always be enabled, even if there is a small performance hit. The way to implement it is to store in the TB.flags for each segment whether the limit must be tested and whether the segment is RW. Fabrice.