From patchwork Fri Oct 27 06:50:45 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Wanpeng Li X-Patchwork-Id: 10029199 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 07B5D6034B for ; Fri, 27 Oct 2017 06:51:05 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id EEBC528E48 for ; Fri, 27 Oct 2017 06:51:04 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E36F128F4E; Fri, 27 Oct 2017 06:51:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9F88F28E48 for ; Fri, 27 Oct 2017 06:51:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752102AbdJ0GvC (ORCPT ); Fri, 27 Oct 2017 02:51:02 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:50701 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751072AbdJ0GvA (ORCPT ); Fri, 27 Oct 2017 02:51:00 -0400 Received: by mail-pf0-f193.google.com with SMTP id b6so4294905pfh.7; Thu, 26 Oct 2017 23:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=/msjgRzZIuc+aSNoxiyGQ72rGcsKML87kg6rfreRD7Y=; b=EpMQQ9LXAvIQok9Tr4hCVqeDPoxzv0exGnVBp21S1u7xSgMo2XZt/+AwK4AanS0uvL fLlnKjWOOgzm8YStabZS0xJu4k1QCXwrArc2h5ZKXRLPNsleh1qnoSiuW0MGdxxFKL2R UGhS2YPKDUz/hURo/qQYw/A3r5fCugQk2ysEAwHbgq0sdcORFqUcERTu1XX+gcqn9H+z GJZnxwBxVhMvuBzPNRTyHKc6RtbnFLIqKxy/LGRkOFFSy2BRZYg5iJXbC8U39zoC8Nea D27ocwE6KBsVnvthxPoPfRZwP1yWeQ4Pbc5RN70oP8LNPXMlhGPP+UmN2C6j51yQMQvU oTbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=/msjgRzZIuc+aSNoxiyGQ72rGcsKML87kg6rfreRD7Y=; b=lrVfkCjzytjHpDrh8w3SQpK9WXBliavtkBFSCqkGSsJhdn7mpOcBiDl4zRU7USthb9 Zr3Ui8DRLarMCwSkurAOvFq0V45r5j0+uRv8kflwSSzg2VGL6+7vQf9daV5uvGULDFhK i75qmx5dwnzGvftlyfO/HGAWLg6QXqqeMPdw4fItANA3o46ONkMSlDynZT1Qvu7djQ6N QA+CWOBR6Wji2Zx18AJUT8VK90zP/y90BRzR1Db9s+QSHLRPpLojJPfh0x/VugV3yr8d ShwLn9IuF65IBbxgr/hzm0COTxV+m+ARD2UIZkWMyHWseFVFx3cgQvgmjdezatIhQPEJ gFMw== X-Gm-Message-State: AMCzsaWExtcZt8VFrPfbSc/vb27eZKNiqV8hYTL9eXRGd0Xli8+h3Gj0 8ZkCRSPdpF/5aBorFcQqnTVLaw== X-Google-Smtp-Source: ABhQp+Q/a3xi/LwTu+mqRLWQSGmdq82dIeJS+eyu59TgowXNxtNZK95Hmo/f9Za4nBggsCyUaNzqaA== X-Received: by 10.99.147.3 with SMTP id b3mr7367244pge.352.1509087059601; Thu, 26 Oct 2017 23:50:59 -0700 (PDT) Received: from localhost ([203.205.141.123]) by smtp.gmail.com with ESMTPSA id j68sm11476539pgc.6.2017.10.26.23.50.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 23:50:59 -0700 (PDT) From: Wanpeng Li X-Google-Original-From: Wanpeng Li To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: Paolo Bonzini , =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= , Wanpeng Li , Nadav Amit , Pedro Fonseca Subject: [PATCH 1/2] KVM: X86: Fix operand size during instruction decoding Date: Thu, 26 Oct 2017 23:50:45 -0700 Message-Id: <1509087046-6401-1-git-send-email-wanpeng.li@hotmail.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Wanpeng Li Pedro reported: During tests that we conducted on KVM, we noticed that executing a "PUSH %ES" instruction under KVM produces different results on both memory and the SP register depending on whether EPT support is enabled. With EPT the SP is reduced by 4 bytes (and the written value is 0-padded) but without EPT support it is only reduced by 2 bytes. The difference can be observed when the CS.DB field is 1 (32-bit) but not when it's 0 (16-bit). The internal segment descriptor cache exist even in real/vm8096 mode. The CS.D also should be respected instead of just default operand-size/66H prefix during instruction decoding. This patch fixes it by also adjusting operand-size according to CS.D. Reported-by: Pedro Fonseca Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Nadav Amit Cc: Pedro Fonseca Signed-off-by: Wanpeng Li --- arch/x86/kvm/emulate.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index 8079d14..7cada51 100644 --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm/emulate.c @@ -5000,6 +5000,8 @@ int x86_decode_insn(struct x86_emulate_ctxt *ctxt, void *insn, int insn_len) bool op_prefix = false; bool has_seg_override = false; struct opcode opcode; + u16 dummy; + struct desc_struct desc; ctxt->memop.type = OP_NONE; ctxt->memopp = NULL; @@ -5020,9 +5022,15 @@ int x86_decode_insn(struct x86_emulate_ctxt *ctxt, void *insn, int insn_len) case X86EMUL_MODE_VM86: case X86EMUL_MODE_PROT16: def_op_bytes = def_ad_bytes = 2; + ctxt->ops->get_segment(ctxt, &dummy, &desc, NULL, VCPU_SREG_CS); + if (desc.d) + def_op_bytes = 4; break; case X86EMUL_MODE_PROT32: def_op_bytes = def_ad_bytes = 4; + ctxt->ops->get_segment(ctxt, &dummy, &desc, NULL, VCPU_SREG_CS); + if (!desc.d) + def_op_bytes = 2; break; #ifdef CONFIG_X86_64 case X86EMUL_MODE_PROT64: