From patchwork Wed Aug 16 11:22:49 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Paolo Bonzini X-Patchwork-Id: 9903487 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 6F6FE6038C for ; Wed, 16 Aug 2017 11:23:20 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5FACB2898F for ; Wed, 16 Aug 2017 11:23:20 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 54925289B5; Wed, 16 Aug 2017 11:23:20 +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.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID 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 F0155289A7 for ; Wed, 16 Aug 2017 11:23:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751584AbdHPLW4 (ORCPT ); Wed, 16 Aug 2017 07:22:56 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:38362 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751196AbdHPLWy (ORCPT ); Wed, 16 Aug 2017 07:22:54 -0400 Received: by mail-wr0-f193.google.com with SMTP id g32so2483305wrd.5; Wed, 16 Aug 2017 04:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=AY2v0aAqX9jdTWkN0tqEgg1bgOfQfXAfx1RsJPSm9tA=; b=F7/1JpA/y2gudx/DTrnOHTH80dRhbAhutygKQYqw5yoF8WK3KALMDlDz40UMmpreKs dIYA4Gqn/6cd2Uxi5IhEX3tE6tjlAs3O7o7CdrN1iP422mzn6S0tETau1ghIJ9goR0Gx 1xonhQq3hYvXteUoq1zkZGJCGahK7eR0D9UfjCU6gIbX77tbsdFbqhpM3VuJ4wcE/4oh DlcMCvNO6QGq7D2AhJVsumMwt6PyQmTTtmDCsjvVK+1Q3JCWfljA565Fbk9Gt5PJpLjQ FEvopxpskNBdYdNxgGgZ6MdvgKYqSaTKfqWiiL6ptl+sHsvEf4ogHIqxET3IEWvTB7U3 Qi5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :mime-version:content-transfer-encoding; bh=AY2v0aAqX9jdTWkN0tqEgg1bgOfQfXAfx1RsJPSm9tA=; b=lX9WPyJHCFgNwCAI4q/WBWXWvOJuFZJ1vJSvgQ11mlwgwt3kInO+xZEuEolnzb22r6 6I7V6PPJTfGGeEZrODbc7c1N0A43UqG9I8vSk0mkXy2gVUI0ESYfKRZp8ybfhl5qFW+s fFWgNlksn/+mFYGx5ypImS7luc+SSQhUK7nOoPmAGSZwBT8ZqlOM/xtIt719c+PaQiDu D1sdNNRDnPY/FwZ22fe4uAjMZmVIROilxznSQWsI0nd9WptsRiYHKbNGdrze9CXurv60 XVm/vVW9U6S+9pvC3Z/mv/LKKFZ29lek49xSE10WdL5ylDbU30llJO7wgdn4TkcxTwUW ltug== X-Gm-Message-State: AHYfb5hI6+rBJ4PBR3V/uTdfb0efDuGRQepOGNB7GYfsw7PKI20PEK1N kqQ3wHrsbxAXeptGRRw= X-Received: by 10.223.150.139 with SMTP id u11mr953851wrb.259.1502882573165; Wed, 16 Aug 2017 04:22:53 -0700 (PDT) Received: from donizetti.redhat.com (94-39-192-75.adsl-ull.clienti.tiscali.it. [94.39.192.75]) by smtp.gmail.com with ESMTPSA id 77sm933148wmt.39.2017.08.16.04.22.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 16 Aug 2017 04:22:51 -0700 (PDT) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: "Michael S . Tsirkin" , =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= , stable@vger.kernel.org Subject: [PATCH] kvm: x86: disable KVM_FAST_MMIO_BUS Date: Wed, 16 Aug 2017 13:22:49 +0200 Message-Id: <20170816112249.28939-1-pbonzini@redhat.com> X-Mailer: git-send-email 2.13.5 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 Microsoft pointed out privately to me that KVM's handling of KVM_FAST_MMIO_BUS is invalid. Using skip_emulation_instruction is invalid in EPT misconfiguration vmexit handlers, because neither EPT violations nor misconfigurations are listed in the manual among the VM exits that set the VM-exit instruction length field. While physical processors seem to set the field, this is not architectural and is just a side effect of the implementation. I couldn't convince myself of any condition on the exit qualification where VM-exit instruction length "has" to be defined; there are no trap-like VM-exits that can be repurposed; and fault-like VM-exits such as descriptor-table exits provide no decoding information. So I don't really see any elegant way to fix it except by disabling KVM_FAST_MMIO_BUS, which means virtio 1 will go slower. Adding a hypercall or MSR write that does a fast MMIO write to a physical address would do it, but it adds hypervisor knowledge in virtio, including CPUID handling. So it would be pretty ugly in the guest-side implementation, but if somebody wants to do it and the virtio side is acceptable to the virtio maintainers, I am okay with it. Cc: Michael S. Tsirkin Cc: Radim Krčmář Cc: stable@vger.kernel.org Fixes: 68c3b4d1676d870f0453c31d5a52e7e65c7448ae Signed-off-by: Paolo Bonzini --- arch/x86/kvm/vmx.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 375dca24cf42..b3eaeb20670d 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -6320,11 +6320,6 @@ static int handle_ept_misconfig(struct kvm_vcpu *vcpu) gpa_t gpa; gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS); - if (!kvm_io_bus_write(vcpu, KVM_FAST_MMIO_BUS, gpa, 0, NULL)) { - trace_kvm_fast_mmio(gpa); - return kvm_skip_emulated_instruction(vcpu); - } - ret = handle_mmio_page_fault(vcpu, gpa, true); vcpu->arch.gpa_available = true; if (likely(ret == RET_MMIO_PF_EMULATE))