Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp4003308pxb; Tue, 2 Nov 2021 02:17:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzXrWgHv/+SXIc2S34dHUG6Tz1eFKBgC69185PBwCWUKCNn34CaFAgUv9ltSgnmuIwym3Iy X-Received: by 2002:a05:6e02:b2e:: with SMTP id e14mr24243356ilu.47.1635844651597; Tue, 02 Nov 2021 02:17:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635844651; cv=none; d=google.com; s=arc-20160816; b=TPlwy8VsbVtnn1aojSSThSF3NM38LRutgOOvCAZpoda41bv0pYfqgkzTROONqhYHGF kRrATBytSH7f/FmjR04enP0/eiPPhUJVK3IZxP1YeYGz+fqXvNRmnDdUzpwwisR6BlBK /HbPj2tWP7FBA/x8ioG1FYo2DQKtnkeD/SBssN62WgACVaLKyvgkYieI8ULFOL2TQR3h jy7GWhKMez55kF6ENrs762s8ws0y+Nb+xguawYDFTOWRVFyDlpI+to0KjtJE3dVqoAMK K7NprjHOFKiqBJmNK2qKfYv8+uzsFP/O/85IPHaHgI4Z0k1w6nIqcTPXc5hq6OeN8mcK XnOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=F4WKqyN17TKXwds8cnhS28rEHbpiFGCXzzZFgIcxC1U=; b=li/4KMHr+yv+Tlrl98Q9PHkXDMmOOhhW1eeiTi642hQYmWVtfOpKkArcD5QKbHuNrK Z2aQv2sEDp5at8qb9nlb40t4mi0uMpuHqOqPdBPf6n7ztD/bVkYG0MhcbOnCZt0wbpNW cp6UVrj6+ZTHe42ZcO3K21a42KbtvkCNtn+FWYHwMze7mwBXQsL/skPZee+r2sZNc23N mgtjEmFNqLiwiWVguq6RjKZ4qDIkzExGgOTFKJv7rXpSvX9hvk26U6TvvwwycYR/p0jZ EnVu5eBl0jXKUpAkDDMk7ZtJg+QEU9/5GZi4nZ5ZqJ1u0N3YEfymCdtG1086ATz+Qoqb 7ppQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k12si9548270iov.104.2021.11.02.02.17.19; Tue, 02 Nov 2021 02:17:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231419AbhKBJSU (ORCPT + 99 others); Tue, 2 Nov 2021 05:18:20 -0400 Received: from out4436.biz.mail.alibaba.com ([47.88.44.36]:5878 "EHLO out4436.biz.mail.alibaba.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231186AbhKBJSN (ORCPT ); Tue, 2 Nov 2021 05:18:13 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R541e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04407;MF=houwenlong93@linux.alibaba.com;NM=1;PH=DS;RN=14;SR=0;TI=SMTPD_---0Uuk0lFW_1635844536; Received: from localhost(mailfrom:houwenlong93@linux.alibaba.com fp:SMTPD_---0Uuk0lFW_1635844536) by smtp.aliyun-inc.com(127.0.0.1); Tue, 02 Nov 2021 17:15:37 +0800 From: Hou Wenlong To: kvm@vger.kernel.org Cc: Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Alexander Graf , linux-kernel@vger.kernel.org Subject: [PATCH v2 4/4] KVM: x86: Exit to userspace if RDMSR/WRMSR emulation returns X86EMUL_IO_NEEDED Date: Tue, 2 Nov 2021 17:15:32 +0800 Message-Id: <56f9df2ee5c05a81155e2be366c9dc1f7adc8817.1635842679.git.houwenlong93@linux.alibaba.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In em_{rd,wr}msr(), it returns X86EMUL_IO_NEEDED if MSR accesses needed to exit to userspace. However, x86_emulate_insn() doesn't return X86EMUL_*, so x86_emulate_instruction() doesn't directly act on X86EMUL_IO_NEEDED, it instead looks for other signals to differentiate between PIO, MMIO, etc... So RDMSR/WRMSR emulation won't exit to userspace now. The userspace_msr_exit_test testcase in seftests had tested RDMSR/WRMSR emulation with kvm.force_enable_prefix enabled and it was passed. Because x86_emulate_instruction() returns 1 and guest continues, but RIP has been updated to point to RDMSR/WRMSR. Then guest would execute RDMSR/WRMSR and exit to userspace by kvm_emulate_{rd,wr}msr() finally. In such situation, instruction emulation didn't take effect but userspace exit information had been filled, which was inappropriate. Since X86EMUL_IO_NEEDED path would provide a complete_userspace_io callback, x86_emulate_instruction() should return 0 if callback is not NULL. Then RDMSR/WRMSR instruction emulation can exit to userspace and skip RDMSR/WRMSR execution and inteception. Fixes: 1ae099540e8c7 ("KVM: x86: Allow deflecting unknown MSR accesses to user space") Signed-off-by: Hou Wenlong --- arch/x86/kvm/x86.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 5eadf5ddba3e..f5573f010a8e 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -8214,6 +8214,9 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, writeback = false; r = 0; vcpu->arch.complete_userspace_io = complete_emulated_mmio; + } else if (vcpu->arch.complete_userspace_io) { + writeback = false; + r = 0; } else if (r == EMULATION_RESTART) goto restart; else -- 2.31.1