Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp3255108pxb; Tue, 12 Jan 2021 09:59:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJyuyj99f7z3BzOXK+3M3PDP2XRqWM2qawQTCrWPm+H05kuL0L+/K1708c1aI5RzI0Yl/Yj1 X-Received: by 2002:aa7:de0f:: with SMTP id h15mr258273edv.372.1610474380986; Tue, 12 Jan 2021 09:59:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610474380; cv=none; d=google.com; s=arc-20160816; b=ebCxx3pekgESj3d7ExLRgSKZaFy1bnDRKeRDM6VZyCOeEjArQiIbRsFCv+fSDHKmoa /J46/RAC8J7pJ7rW8yuG0gJdGhkHe9JKDtxi4zhxFHQHazoUiGloCbs7aHIy7qagmD4L xOrO82bV8ZGNvkB0hdp/EkSXWC33M0MtsaMuxoXJ2XBrDF0NOgv+ZoYHE0/gyM5zxVh4 J2thdRSx693YPklOKauGqfXdPTKhjmocw1/7CCDHOWs4u+/ECkWi2OVkQUZqjTfOz3Pr 0PeMzkmqXJO4ytNJIAxgo4WyrbsGvx8cFvGCHvD169jnwpn91yAa55nw2BXqUoHff+8C 2EeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=juupzti4DjJGDkZymRZ4Hc4aNwh9m6UznVRuz/k6aiY=; b=NblxajVS1X8MnN8RvDvkuh0COiN+L4xDgbJP+JsIeeAHj+ItkrdH3jDxcMYDCAxEzP tdEh5lxG1SYl2Se3f4jiPGdwY/5mbnKfEPE0gKW8YocJEmZ70TrdRQk0aQZbBc+afyxM XQAMxZVDfDLfYnHt0mViQaj30PCG7QGmwhjCX74K2WyUUSc+CtGOU/mAxOnd58qL9do3 iIqOqfJnvtd53tszXrm9p2x1IN7licScfkx8fDiaxlpmE7Vkn20tHoEMc14y4GiappXr xhl0Tj6Tb774yg7gVcq/SZC8fCjAbsCtEr06W/a0NQyT5dulYrhRrihRvi/C45vKvlLT igTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=D60dxrI8; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z27si24885ejf.110.2021.01.12.09.59.16; Tue, 12 Jan 2021 09:59:40 -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=@google.com header.s=20161025 header.b=D60dxrI8; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391754AbhALR5m (ORCPT + 99 others); Tue, 12 Jan 2021 12:57:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53698 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730203AbhALR5l (ORCPT ); Tue, 12 Jan 2021 12:57:41 -0500 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40075C061575 for ; Tue, 12 Jan 2021 09:57:01 -0800 (PST) Received: by mail-pj1-x1030.google.com with SMTP id y12so2086714pji.1 for ; Tue, 12 Jan 2021 09:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=juupzti4DjJGDkZymRZ4Hc4aNwh9m6UznVRuz/k6aiY=; b=D60dxrI8s7RNFc+y8vuVvZajug7r9YdHgFOUSCbNl3jQHnymRLHAQs8PA9hCQtCiJp /a8zU0IqB1a5PFkVIO71nW8vOFQyfvmzrBa5e+y/bIkaSx8OAFqmV0Jvw7W/J3xfdTBG mAvtHc1Quj9Bs6vf3J4NI+Fi2bdAh5GDrUnNoyhOl8f9v8bb5sOg425c1unqaXDj0kad sJKHBudJqInEYt1KvW5/ptn6QaEcgxikAQVfItlwAxiZajIH/X3qK1WBCABeFeJF/sKC viQOgBSkd77iH8Phoe4et2xOHWTmd2Y+721p9vVSTYAf80hsyFnHz5WZzw7YpqIcpWCT hHXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=juupzti4DjJGDkZymRZ4Hc4aNwh9m6UznVRuz/k6aiY=; b=JXpeBvBw+YaC2UH3SnPTfkLLthq8RD+IIquAiZYNgSxZcBgFOQyOy7+G5Pv3i69TPG JZUadMM/2jPM5pGf20y7U0lj4PHwbirMGPhTO78jPo75mnahpPNz+cuMm4WPzR2wEww2 cvcQaWJpmWWnDlMIRFdXx4AD1kwocDyWj/W1+swVxGVQwOPkSL+Z42C1yqxX8SbTuLFK UhBlbYT+sS7G0AAN4dJs8xMFqCCHVwJlIG45TiyPnLUZhZYfjNionoAbm/JVLuz7pOE7 StGrU2nSmDyWK+dx0FXAiuY7x9BgGUWTh4N+akt+d1VYKDz9VJHkgvCV7PYUxk0Bx5UC /Ong== X-Gm-Message-State: AOAM530iF4kKglMZEeqARjl/PWCEtGqdL/OtK8GmMhTT/GEQYmZy3XwJ V1cS5zkwAR9mObNzDZMio5/YLC6I373Z/w== X-Received: by 2002:a17:90a:5513:: with SMTP id b19mr267855pji.99.1610474220588; Tue, 12 Jan 2021 09:57:00 -0800 (PST) Received: from google.com ([2620:15c:f:10:1ea0:b8ff:fe73:50f5]) by smtp.gmail.com with ESMTPSA id 17sm3821852pfj.91.2021.01.12.09.56.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Jan 2021 09:56:59 -0800 (PST) Date: Tue, 12 Jan 2021 09:56:52 -0800 From: Sean Christopherson To: Andy Lutomirski Cc: Bandan Das , Maxim Levitsky , Vitaly Kuznetsov , Wei Huang , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, pbonzini@redhat.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 Message-ID: References: <8FAC639B-5EC6-42EE-B886-33AEF3CD5E26@amacapital.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8FAC639B-5EC6-42EE-B886-33AEF3CD5E26@amacapital.net> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 12, 2021, Andy Lutomirski wrote: > > > On Jan 12, 2021, at 7:46 AM, Bandan Das wrote: > > > > 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" > >>>>>> > >>>>>> 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); > >>>>>> > >>>>>> +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? > >>>> > >>> To reduce the scope of the workaround. > >>> > >>> 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’t 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. > > Ask AMD? > > I would also believe that someone somewhere has a firmware that simply omits > the problematic region instead of listing it as reserved. I agree with Andy, odds are very good that attempting to be precise will lead to pain due to false negatives. And, KVM's SVM instruction emulation needs to be be rock solid regardless of this behavior since KVM unconditionally intercepts the instruction, i.e. there's basically zero risk to KVM.