From patchwork Mon Nov 6 00:54:47 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Wanpeng Li X-Patchwork-Id: 10042453 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 7EC4B601EB for ; Mon, 6 Nov 2017 00:56:22 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 902F52920A for ; Mon, 6 Nov 2017 00:56:22 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 834CC29225; Mon, 6 Nov 2017 00:56:22 +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 E574D2920A for ; Mon, 6 Nov 2017 00:56:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751141AbdKFAyz (ORCPT ); Sun, 5 Nov 2017 19:54:55 -0500 Received: from mail-pg0-f66.google.com ([74.125.83.66]:43147 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750910AbdKFAyy (ORCPT ); Sun, 5 Nov 2017 19:54:54 -0500 Received: by mail-pg0-f66.google.com with SMTP id s75so6924919pgs.0; Sun, 05 Nov 2017 16:54:53 -0800 (PST) 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=V5y/41gCEU2LXP5VEluyiEfcaY7Gme2G/wiE0Q854C4=; b=JSJBFacLWhboI9PScR/JoDlkjKTSdaKqOgZuCbYdsRVljgmmmnHgkDqMLq06+7/S2M 4BvhOQr9cv2DzgTQusxAlgZ4PtUh/fJjYl64T/Wlp60ynmJ5ybJxJc5GEqJBuJoOFtyW RiQ4NO5Ti8dvEh5YVq07Mo8htjctP982FHqMY+HpE4d4A/OeL8UXFzLYZFS+0kjWZXkh qQEXz1stNnFSraNLTNXqFTuIu2IDAFt8u2zMdQoulqXTXGZQxVKyU42ABlq6ShpfO0+Z Ub+dHh7+LSq1QtGkyw4ZXG0uz2sdVRRLcaBkAq1JadrL2nI44D+etENLBX9+r4YMTnnb T8tQ== 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=V5y/41gCEU2LXP5VEluyiEfcaY7Gme2G/wiE0Q854C4=; b=uni+jIDsROKnXrbsRGmZjJPg8UduwzXk94UoickjznQiObhAnnkIj2xi+DvlaGO+o7 nP7k5J6QHRMzIjsUZEsF8bn3V722P7PEcFUZeBP78rcmtowzRxZNHEbo19Icwy/in9Xc l6CazbCuSifaM/OqrkCnOipwex//6l3bYrWYKkgz0Y9K9S7RjNM1+1Ok6iv4OlrCBklx QIyLPsIW9B/rNH1IJqpbPiQVTvLL98dpC2FGjM0E5b3LPhFHAzE8Bga9VyDQFCS6NY68 RKO1gQ/Xg47B7dznscbua3nYvj/gFZoincjgNTxlTglF2xZVUV0sPKWIw0HRAMWQPSJX U+aw== X-Gm-Message-State: AMCzsaUarBuZnkxVPo0tqzus9PvMsvSUe7abR3EFXKkoZ4sG83vrmWi1 BpAMH5bt4p1M+Pg3eLqwgIgbxA== X-Google-Smtp-Source: ABhQp+TxcfXin6v5mz/wygq37wWMQ5CM86aP6OukSYai4c4Axz8TVQ2bdgDAM/UnkPOTlbk/mmx82A== X-Received: by 10.101.85.9 with SMTP id f9mr13803159pgr.263.1509929693290; Sun, 05 Nov 2017 16:54:53 -0800 (PST) Received: from localhost ([203.205.141.123]) by smtp.gmail.com with ESMTPSA id h8sm14309862pgq.82.2017.11.05.16.54.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Nov 2017 16:54:52 -0800 (PST) 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 v6 1/3] KVM: X86: Fix operand/address-size during instruction decoding Date: Sun, 5 Nov 2017 16:54:47 -0800 Message-Id: <1509929689-2935-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/address-size/66H prefix/67H prefix during instruction decoding. This patch fixes it by also adjusting operand/address-size according to CS.D. Reported-by: Pedro Fonseca Tested-by: Pedro Fonseca Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Nadav Amit Cc: Pedro Fonseca Signed-off-by: Wanpeng Li Reviewed-by: Paolo Bonzini --- v4 -> v5: * cleanup patch subject/description v3 -> v4: * def_ad_bytes must be changed to 4 * separate X86EMUL_MODE_PROT16 altogether from the others v2 -> v3: * cleanup the codes v1 -> v2: * respect cs.d for real/vm8096, other modes have already been considered in init_emulate_ctxt(). arch/x86/kvm/emulate.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index 8079d14..b4a87de 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; @@ -5018,6 +5020,11 @@ int x86_decode_insn(struct x86_emulate_ctxt *ctxt, void *insn, int insn_len) switch (mode) { case X86EMUL_MODE_REAL: case X86EMUL_MODE_VM86: + def_op_bytes = def_ad_bytes = 2; + ctxt->ops->get_segment(ctxt, &dummy, &desc, NULL, VCPU_SREG_CS); + if (desc.d) + def_op_bytes = def_ad_bytes = 4; + break; case X86EMUL_MODE_PROT16: def_op_bytes = def_ad_bytes = 2; break;