From patchwork Wed Nov 17 01:28:04 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Stefan Reinauer X-Patchwork-Id: 71504 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 0409AB7155 for ; Wed, 17 Nov 2010 12:43:44 +1100 (EST) Received: from localhost ([127.0.0.1]:50404 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIX3l-0002Tk-7n for incoming@patchwork.ozlabs.org; Tue, 16 Nov 2010 20:43:41 -0500 Received: from [140.186.70.92] (port=36989 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIX2Y-0001t1-Vu for qemu-devel@nongnu.org; Tue, 16 Nov 2010 20:42:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PIWoi-0005j7-IW for qemu-devel@nongnu.org; Tue, 16 Nov 2010 20:28:09 -0500 Received: from smtp-out.google.com ([74.125.121.35]:25925) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PIWoi-0005iu-AJ for qemu-devel@nongnu.org; Tue, 16 Nov 2010 20:28:08 -0500 Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id oAH1S5cp015816 for ; Tue, 16 Nov 2010 17:28:05 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1289957285; bh=GVQPQjX4p7kvXDv2tooIUuntnKU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type:Content-Transfer-Encoding; b=XybRwa4t3zwrJCZvA9AmQNx9fk58GhiMaR+klve2bdz5LqLGQr5jJAw/UryNQNTd3 vRGgQkWhdvYOmEPkVM1Tg== Received: from qyk38 (qyk38.prod.google.com [10.241.83.166]) by hpaq3.eem.corp.google.com with ESMTP id oAH1Qcle011259 for ; Tue, 16 Nov 2010 17:28:04 -0800 Received: by qyk38 with SMTP id 38so5480175qyk.9 for ; Tue, 16 Nov 2010 17:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=k9k7IqzItw2qj0w0pGVkfFanAOWhaYkGp8Ri31AJTZI=; b=I7tXAoqR1cvqMFc1Rqc9F1umarv95v2Qf43dF8h1zXZjc179SAq3UKRboZaygc4Muw gFf9rRbb0D52BHCu3T2w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=FPwAK8LqW95m6YJaUOAhCW+QCwn7Nq5jxT1LKdIAnlOkBtjSHlhx539IDrkQvsQpZw +AcIFiGuiMgG9Ach/Qzw== MIME-Version: 1.0 Received: by 10.229.97.11 with SMTP id j11mr7041363qcn.113.1289957284148; Tue, 16 Nov 2010 17:28:04 -0800 (PST) Received: by 10.229.8.134 with HTTP; Tue, 16 Nov 2010 17:28:04 -0800 (PST) In-Reply-To: References: Date: Tue, 16 Nov 2010 17:28:04 -0800 Message-ID: From: Stefan Reinauer To: qemu-devel@nongnu.org X-System-Of-Record: true X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: [Qemu-devel] Re: SMM jmp weirdness X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Thu, Nov 11, 2010 at 4:53 PM, Stefan Reinauer wrote: > Hi, > > I'm looking at the following piece of code running under QEMU > >   0x38000:     66 bd 90 f8 27 3f       mov    $0x3f27f890,%ebp ; > target address for jmp >    0x38006:     66 2e 2b 2e f8 fe       sub    %cs:0xfef8,%ebp    ; > subtract SMBASE >    0x3800c:     66 ff e5                     jmpl   *%ebp > > The code is run in system management mode and should eventually jump > to 0x3f27f890. However, that jump fails and QEMU continues code > execution at 0x3800f. I suspect this is due to some missing SMM > special case in translate.c:disas_insn() in the jmp Ev path, but I'm > not sure yet where to go from there. > Can anyone toss me in the right direction? The good thing: I was wrong, that jmpl seems to work like intended. Thanks to Alex Graf for pointing me in the right direction for debugging. However, a few instructions later, the code encounters this instruction: 0x3f2af89e: e8 05 0b 00 00 call 0x3f2a03a6 We're in SMM, but with CS limit set to 4GB. However, stepping into this instruction we end up at 0x303a6. Remember, CS is 0x3000. So applying the following patch gets us beyond this point, but it is a bit of a hack: tval &= 0xffffffff; With this change the code gets to the point of "ret" where a similar change would be needed. Generally a lot of &= 0xffff mentioned in the translate.c code seems to be incorrect, and should rather be &= env->segs[R_CS].limit or similar. The same applies for gen_op_andl_T0_ffff(); which should rather be called gen_op_andl_T0_seg_limit(); and behave accordingly. Stefan --- a/target-i386/translate.c +++ b/target-i386/translate.c @@ -6257,7 +6257,7 @@ static target_ulong disas_insn(DisasContext *s, target_ulong pc_start) tval = (int16_t)insn_get(s, OT_WORD); next_eip = s->pc - s->cs_base; tval += next_eip; - if (s->dflag == 0) + if ((s->dflag == 0) && !(s->flags & HF_SMM_MASK)) tval &= 0xffff; else if(!CODE64(s))