Received: by 10.223.176.46 with SMTP id f43csp873971wra; Wed, 24 Jan 2018 07:14:25 -0800 (PST) X-Google-Smtp-Source: AH8x22547V3kqfz3KXlGxp8tmDEvsssD/6PF8o2l39xJkdyIGRZIPZAeVEVUnck/5O1Oi0Loi9O8 X-Received: by 2002:a17:902:c01:: with SMTP id 1-v6mr8135161pls.55.1516806864957; Wed, 24 Jan 2018 07:14:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516806864; cv=none; d=google.com; s=arc-20160816; b=0jHD9MQdgLJ9DlQAvFVp4Bdd9wpouOqX4mVYe3Hzj31leYleeaECZfrIa754CFa24I I7L/bROptW3JXnGi7CpJ6QsHZFvSYtavh41jBKR1FFOopEmjqfs4eS4jrdw+N4+4gJg4 x6SmQLz6nnHDwAd/VgUZjND/LaRi+lrpgYOjiiWdjWAiA2wMbp33EmxNwMwQqS+VPSmj BNn/a7qCdGK4PIqvY7+OebwKO+cwirdfzgNTYHdvHoDLUfCvPmHI5HAqCqiGX3uHHl3X KX78omB/EpAdRi9HKa6yb4MWiX7XKQmTIKFmTPFnMOFPteeFQnT1pNvwHYMl7r1UBXpC mPjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=Si2aQpqAkIeBRibOKk1CdDcQjufgRx/xFsZQ4KlvTH4=; b=dYUpW81m5+G2vPkABOkhD8vX8UBn6HVmHiae7GTQKjgO2XyaBN7y8vZHeiLQRoOkrp Sb9OvIsHyR3ftXbqDMAlGMylf2a3dbX35uHO6GK1/EI4guvKKVZ+npasuPf+URdqOwyh QKFsNyIsSuAIoQ55isdLlrzELPooJ6FuswjUO5/O+eAwqP1jnUX9B6orNFio0HS9nTA5 2D0FfyLQCOnaYFLzKrlzqU+62jk1AKvB/sOjUDiyivJdg9SHSXFZ5rcAM82T5HmxpZMU dqoM6o/lGGHflkPkCFsNa0FbtIO1WA/Hd1HuGAKk8wfUOvrUkVZiIooTAHjTFeq24YU5 71lA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t62si3046954pfa.49.2018.01.24.07.14.11; Wed, 24 Jan 2018 07:14:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934185AbeAXPMt (ORCPT + 99 others); Wed, 24 Jan 2018 10:12:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38678 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934033AbeAXPMr (ORCPT ); Wed, 24 Jan 2018 10:12:47 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8262B7E426; Wed, 24 Jan 2018 15:12:47 +0000 (UTC) Received: from vitty.brq.redhat.com (unknown [10.43.2.155]) by smtp.corp.redhat.com (Postfix) with ESMTP id 80C4919425; Wed, 24 Jan 2018 15:12:35 +0000 (UTC) From: Vitaly Kuznetsov To: kvm@vger.kernel.org Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini , =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= Subject: [PATCH] x86/kvm: disable fast MMIO when running nested Date: Wed, 24 Jan 2018 16:12:34 +0100 Message-Id: <20180124151234.32329-1-vkuznets@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 24 Jan 2018 15:12:47 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I was investigating an issue with seabios >= 1.10 which stopped working for nested KVM on Hyper-V. The problem appears to be in handle_ept_violation() function: when we do fast mmio we need to skip the instruction so we do kvm_skip_emulated_instruction(). This, however, depends on VM_EXIT_INSTRUCTION_LEN field being set correctly in VMCS. However, this is not the case. Intel's manual doesn't mandate VM_EXIT_INSTRUCTION_LEN to be set when EPT MISCONFIG occurs. While on real hardware it was observed to be set, some hypervisors follow the spec and don't set it; we end up advancing IP with some random value. I checked with Microsoft and they confirmed they don't fill VM_EXIT_INSTRUCTION_LEN on EPT MISCONFIG. Fix the issue by disabling fast mmio when running nested. Signed-off-by: Vitaly Kuznetsov --- arch/x86/kvm/vmx.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index c829d89e2e63..54afb446f38e 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -6558,9 +6558,16 @@ static int handle_ept_misconfig(struct kvm_vcpu *vcpu) /* * A nested guest cannot optimize MMIO vmexits, because we have an * nGPA here instead of the required GPA. + * Skipping instruction below depends on undefined behavior: Intel's + * manual doesn't mandate VM_EXIT_INSTRUCTION_LEN to be set in VMCS + * when EPT MISCONFIG occurs and while on real hardware it was observed + * to be set, other hypervisors (namely Hyper-V) don't set it, we end + * up advancing IP with some random value. Disable fast mmio when + * running nested and keep it for real hardware in hope that + * VM_EXIT_INSTRUCTION_LEN will always be set correctly. */ gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS); - if (!is_guest_mode(vcpu) && + if (!static_cpu_has(X86_FEATURE_HYPERVISOR) && !is_guest_mode(vcpu) && !kvm_io_bus_write(vcpu, KVM_FAST_MMIO_BUS, gpa, 0, NULL)) { trace_kvm_fast_mmio(gpa); return kvm_skip_emulated_instruction(vcpu); -- 2.14.3