Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp3164777pxb; Tue, 12 Jan 2021 07:52:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJzC50GbUT225QjuMMACLNiB/AUHLSP+0gthrnFHi493NKTsnDW7b7E9XoK9nKd5QxDILp8E X-Received: by 2002:a17:907:b01:: with SMTP id h1mr1479026ejl.450.1610466738874; Tue, 12 Jan 2021 07:52:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610466738; cv=none; d=google.com; s=arc-20160816; b=qRY37pOmZy7sDOWI2sWJvTWKxCENEViyPkfMGQsQjyHpLp3cW/HfWrFTqWvRO2lw83 Vn6mh2xkDS8tzpK5uz+qmGJhUOIyNVFDcBsebRGsuw1ulAmDYDuelACq7h/gpkN1TgP7 rUGET1ddRw0BN4EnsmruCMAKm/GyJRV5WmN5Fw2mDHLBhUzkWqR18z2iUZ356dqsQWE6 fdk0bP0iwg2bRZPSbUh0Ns4u1+xiMNhHLJyvzwOwFghMCrSr8K5RIenDcX4xx6DR+mbv N1gDgHxNdi9TmwNUGRlc35v5guPbzIdjnbZ2DCuw71Sa0ojOpCLHkcjm7BRXkBBp+Frr tUZQ== 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 :user-agent:message-id:in-reply-to:date:references:subject:cc:to :from:dkim-signature; bh=4jiwV7AuQsPxZcRY14JFnrQvYVeLgEnELmlaS2CrL8E=; b=xHxPlH4wvH1EpqXipNiVy7+odxYTMac/ixLCCw1+SUnDroaic6fYn29CVcUJ5vbH1R ssth74rJNkgHxGHsuRY1NPbNwfmJlUDQqLuEJHggJzHvV4oYVdzfENEb2e9BfkoNWylQ qi/CSw2pOIQ9JJA+/fLjcTxKoAOQTz69/lNVCgN6qXXqHJ3FbnLU1TbDOJqESiW5SBmP ui16pTSswwg/FRddHeIqUpJtlHXmKD+EX2AOpsUS3r2+WAnJEV28AZ9OwTYexcb9KVx8 DRPH4EKfwYb+sB6BrA6Dz9LuJiM+SvVULm/mA7kCDsd/2eTarJEbtAdYs5mBbLYtRxDT OxPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=W9o26myX; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bt17si1289920ejb.333.2021.01.12.07.51.54; Tue, 12 Jan 2021 07:52:18 -0800 (PST) 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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=W9o26myX; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405274AbhALPsA (ORCPT + 99 others); Tue, 12 Jan 2021 10:48:00 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:57630 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405185AbhALPr7 (ORCPT ); Tue, 12 Jan 2021 10:47:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610466392; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4jiwV7AuQsPxZcRY14JFnrQvYVeLgEnELmlaS2CrL8E=; b=W9o26myX74dhL5OuzEWHs42xUbxdPKUJYN3Xjg1zPsqu8t/14D8eVomzr0vpGECi6qpUp0 rB7gpIluTguZwpydGM0cBK7d8UhBPFcGZ00iYCUhKgnpWxNN63x5sLljFy7dslTrrHgAvr NmS/D4PhDHXRL5MWiki3K5Vu7HbKGvk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-584-vobvzLUAPUyzqf0r_KCbag-1; Tue, 12 Jan 2021 10:46:31 -0500 X-MC-Unique: vobvzLUAPUyzqf0r_KCbag-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 95388100C66E; Tue, 12 Jan 2021 15:46:27 +0000 (UTC) Received: from gigantic.usersys.redhat.com (helium.bos.redhat.com [10.18.17.132]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DBC8077BF5; Tue, 12 Jan 2021 15:46:25 +0000 (UTC) From: Bandan Das To: Andy Lutomirski Cc: Maxim Levitsky , Vitaly Kuznetsov , Wei Huang , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, pbonzini@redhat.com, seanjc@google.com, joro@8bytes.org, bp@alien8.de, tglx@linutronix.de, mingo@redhat.com, x86@kernel.org, jmattson@google.com, wanpengli@tencent.com, dgilbert@redhat.com Subject: Re: [PATCH 1/2] KVM: x86: Add emulation support for #GP triggered by VM instructions References: <9f3b8e3dca453c13867c5c6b61645b9b58d68f61.camel@redhat.com> Date: Tue, 12 Jan 2021 10:46:25 -0500 In-Reply-To: (Andy Lutomirski's message of "Tue, 12 Jan 2021 07:22:41 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andy Lutomirski writes: ... >>>>> #endif diff --git a/arch/x86/kvm/mmu/mmu.c >>>>> b/arch/x86/kvm/mmu/mmu.c index 6d16481aa29d..c5c4aaf01a1a 100644 >>>>> --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ >>>>> -50,6 +50,7 @@ #include #include #include >>>>> +#include #include >>>>> "trace.h" >>>>>=20 >>>>> extern bool itlb_multihit_kvm_mitigation; @@ -5675,6 +5676,12 @@ >>>>> void kvm_mmu_slot_set_dirty(struct kvm *kvm, } >>>>> EXPORT_SYMBOL_GPL(kvm_mmu_slot_set_dirty); >>>>>=20 >>>>> +bool kvm_is_host_reserved_region(u64 gpa) +{ + return >>>>> e820__mbapped_raw_any(gpa-1, gpa+1, E820_TYPE_RESERVED); +} >>>> While _e820__mapped_any()'s doc says '.. checks if any part of >>>> the range is mapped ..' it seems to me that the real >>>> check is [start, end) so we should use 'gpa' instead of 'gpa-1', >>>> no? >>> Why do you need to check GPA at all? >>>=20 >> To reduce the scope of the workaround. >>=20 >> The errata only happens when you use one of SVM instructions in the >> guest with EAX that happens to be inside one of the host reserved >> memory regions (for example SMM). > > This code reduces the scope of the workaround at the cost of > increasing the complexity of the workaround and adding a nonsensical > coupling between KVM and host details and adding an export that really > doesn=E2=80=99t deserve to be exported. > > Is there an actual concrete benefit to this check? Besides reducing the scope, my intention for the check was that we should know if such exceptions occur for any other undiscovered reasons with other memory types rather than hiding them under this workaround. Bandan