Received: by 10.223.176.46 with SMTP id f43csp1911706wra; Thu, 25 Jan 2018 01:56:15 -0800 (PST) X-Google-Smtp-Source: AH8x224FzV/5UmeDpjPAv0PFSb3CosGPm4Fphtbz28QdHx4+V5cs9+xtNQ8t3a4pe9+wrRM7MSQ9 X-Received: by 10.101.77.144 with SMTP id p16mr13160137pgq.106.1516874175713; Thu, 25 Jan 2018 01:56:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516874175; cv=none; d=google.com; s=arc-20160816; b=hDywARIiK3F1BOhhPiWH3eQ9/FkMGlOLbhaOI5lJU7g3vLZlPfkbGCRans1GJ4v/fV 5AKGxc0L73r2ttPx9KdK1dEV+/7sDU08yW7k0TjUwrX2bThTZfxA7jK1H2NH9fV9JsGj zq3fzGlqul128ecaoFeJRthIIhUqVKF6vShq9/slrkVa30rYwouZrahbbZvvkR/cxkqV 0XdztLeTlNkWPvY84rwhhDQUJtykmUn2W3NemrqLcIfTiKRVBVkG27ikFwHp7rL4q8AA PaBTY8TlrL57/obTKwoVDf6S+brCQSLp4n2yM8fhTyAwk1yX4zWWki/VEBR8bKAN4y6D sdsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition :content-transfer-encoding:subject:cc:to:from:date:message-id :mime-version:dkim-signature:arc-authentication-results; bh=avo4Zc1L1pqM4nNk062zKsbIw46Rh50rZgk96OVblRk=; b=QST5NKmY3vfVieq0B2ULNAPLu5iQ2Omv9Ci7P2qpb6kY9GolC8TlTMpv/JUeen0P0L 9bAruJrsKyuG3kQ6fFJPTF4YtETfxNoTqV5rn3WqqCqzxvI6p5eek7zqy8SDnnVGHcr6 ZBYeIAHBAySd1iwc7Cn8j4PGe3sBqWjCNLX/iK932t8/DoDpoRWxIGW7LDOgzTFVAx+C MT4SnnOEQ5u6pSHk9eAePvtxplOC7EWHnBy8HUDJtFrjY5zzPJ3F/sZQtD4rxqo+ZZ2x N0jmZ8buFkHe1aOyaV4v8Y319QsL5VrNbdWqELGAAOzH2bMMSifBMxrsKCi6fZLawosc iCAQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=boEAhGQ8; 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=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d5si4428609pfm.149.2018.01.25.01.56.01; Thu, 25 Jan 2018 01:56:15 -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; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=boEAhGQ8; 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=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751497AbeAYJzO (ORCPT + 99 others); Thu, 25 Jan 2018 04:55:14 -0500 Received: from aserp2120.oracle.com ([141.146.126.78]:59580 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751171AbeAYJzM (ORCPT ); Thu, 25 Jan 2018 04:55:12 -0500 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0P9paJL193726; Thu, 25 Jan 2018 09:55:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : to : cc : subject : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=avo4Zc1L1pqM4nNk062zKsbIw46Rh50rZgk96OVblRk=; b=boEAhGQ8LpCXgy1Iol5AE+9dl6XGqtkunIIGfhjnylHq0nyQ2tGHRmf+18qJq00KBzUJ NAvUP9BIfoLsW9gKjXHLtTovhY9pXioe8JTCXwZwziA2Qwtpe1sp0bH1ZBOfy7AjLL8i MaTUt1ntsPkVjAIf7sxeelOb9ZUVKz5mqpw1eJqmlUwKtvGZ5m2fHsBdUtW+/ddrAd+5 1PwZIaRoajNOSl6DcnwtGlXa7YN7i7eThcZEp+Pm3alFqCaVREnuczXDk8a2H+AqPsq8 FkqnStg0d1bNpjSSIZHwPrpYWoF+QNzYwWlgA0exL04cfkrUfF4DjQZDoKqiwwjKAF3f Rw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2fqcqm04a4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Jan 2018 09:55:08 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w0P9t77U017127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 25 Jan 2018 09:55:07 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w0P9t6YI021442; Thu, 25 Jan 2018 09:55:06 GMT MIME-Version: 1.0 Message-ID: <6690c53c-fc99-44ea-9090-6e7438c1bc98@default> Date: Thu, 25 Jan 2018 01:55:06 -0800 (PST) From: Liran Alon To: Cc: , , , , Subject: Re: [PATCH] x86/kvm: disable fast MMIO when running nested X-Mailer: Zimbra on Oracle Beehive Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8784 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=747 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801250137 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- vkuznets@redhat.com wrote: > I was investigating an issue with seabios >=3D 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. >=20 > 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. >=20 > I checked with Microsoft and they confirmed they don't fill > VM_EXIT_INSTRUCTION_LEN on EPT MISCONFIG. >=20 > Fix the issue by disabling fast mmio when running nested. >=20 > Signed-off-by: Vitaly Kuznetsov > --- > arch/x86/kvm/vmx.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) >=20 > 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) > =09/* > =09 * A nested guest cannot optimize MMIO vmexits, because we have an > =09 * nGPA here instead of the required GPA. > +=09 * Skipping instruction below depends on undefined behavior: > Intel's > +=09 * manual doesn't mandate VM_EXIT_INSTRUCTION_LEN to be set in VMCS > +=09 * when EPT MISCONFIG occurs and while on real hardware it was > observed > +=09 * to be set, other hypervisors (namely Hyper-V) don't set it, we > end > +=09 * up advancing IP with some random value. Disable fast mmio when > +=09 * running nested and keep it for real hardware in hope that > +=09 * VM_EXIT_INSTRUCTION_LEN will always be set correctly. If Intel manual doesn't mandate VM_EXIT_INSTRUCTION_LEN to be set in VMCS o= n EPT_MISCONFIG, I don't think we should do this on real-hardware as-well. -Liran > =09 */ > =09gpa =3D vmcs_read64(GUEST_PHYSICAL_ADDRESS); > -=09if (!is_guest_mode(vcpu) && > +=09if (!static_cpu_has(X86_FEATURE_HYPERVISOR) && !is_guest_mode(vcpu) > && > =09 !kvm_io_bus_write(vcpu, KVM_FAST_MMIO_BUS, gpa, 0, NULL)) { > =09=09trace_kvm_fast_mmio(gpa); > =09=09return kvm_skip_emulated_instruction(vcpu); > --=20 > 2.14.3