Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp4567724ybe; Mon, 16 Sep 2019 14:36:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqzMGbhRUeXUHwl5msIakvhgz5NW8xuuo49r5dmboUr0QHozZBsvBn6cFeX6pltPTs17WEOV X-Received: by 2002:a50:d718:: with SMTP id t24mr1447287edi.168.1568669783063; Mon, 16 Sep 2019 14:36:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568669783; cv=none; d=google.com; s=arc-20160816; b=wZCC9vNHI3wIJbDEryFPA5U5O16Syfpy9olzZESLZLMf2UB3XZF91iLrhPeDhbSvIh P2CnP1b3NtDboD4emMvnQhFMWy8nATdVgZMYpMmYeetoUl9Ndstf0EZQlhbJoDTCzqtx ruGvOdmAwwcpL5FfwRPgI/ZlIxFdmK1mwCxOIfrvi9oH7ep0DcfiUKS6a2Vod2s2NXnr vjXjhiN8dDQurxsKr9jVYr2J1nLktKmRQJxeHQT4MT/69+wI+B86lzKJSYOcs542O34I 2jMu5HJTZDKtaeZDv/utJkJr4AU5xSkNX9VM44o7aJ1Yb+WkueXA8FOoLMRHJtrkMdhg eP1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=CK2Hw2Vm0/m4pdvX+3V10oRo4TFnQxQIXBdeHzhGxm4=; b=DEKnUqj/MMZwVZAxKB6PtEipMI7QabcoiD2qGCL4D8bwA8rNiafR4ejvOE4CbwJiOS 9TVHpVSmpWWQF8D/vAe+lDSKulj7g1xuhCW+LlUztYKrGSsWb79SPAZvsaPLOhaqwwI2 IeIFg4D1yD6KqnpkMpeDlwMlYM9PeEdEPzXbPBfCDt4Ypwji5+a/9uOpRXG/nWV+1uq0 /x4mOL7EgjOXYSLNi5hy68aCHogqVIbB8ajC8Bno8ELjXY2jCh+2b0GYRK7GyATrRv4D HPP6E9OgulnXlpsts4kWmHDIxXRQULNBbCTm25hI1/JqR0XVXA9xGlWtgRNqYkPKkuqR HcXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=CvMLlj9S; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id me9si76817ejb.280.2019.09.16.14.35.59; Mon, 16 Sep 2019 14:36:23 -0700 (PDT) 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=@google.com header.s=20161025 header.b=CvMLlj9S; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390000AbfIPQem (ORCPT + 99 others); Mon, 16 Sep 2019 12:34:42 -0400 Received: from mail-io1-f65.google.com ([209.85.166.65]:37724 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389984AbfIPQem (ORCPT ); Mon, 16 Sep 2019 12:34:42 -0400 Received: by mail-io1-f65.google.com with SMTP id b19so556592iob.4 for ; Mon, 16 Sep 2019 09:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CK2Hw2Vm0/m4pdvX+3V10oRo4TFnQxQIXBdeHzhGxm4=; b=CvMLlj9S+eWlpKN4KKfhPU33Ml2oTWcxMncEM0lAbDja/TSaJTwoykGCT7mY3RvsIW 8KqA7Xn35m+HodATZhJD8C7wG4+bc11fdt3gWpjDmcHgqGoynQcRdpLZfuwqSMrMhyoi 6AIz8dbTJqQsQXONcb2NPqWQCNgcfjbD7sCUNjEr6paE+5xLjIeaNW7BijxQdCWYfKWZ PYfS6J8Z3FkQ7QL3FwtOelGVa4RI8MA8XaAUK21eJIR0ZABE0SGEoHZ0yYsVEIox7IES GFWVvEnJohvLD6mbj8Yr8WkD5Ze5m11rqjg/8Tv0wFV+uZCn1m0cQcUEt5GG/ToV2Lxw wuGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CK2Hw2Vm0/m4pdvX+3V10oRo4TFnQxQIXBdeHzhGxm4=; b=Hw2XqWPMg8LD6MX6Kor4unN4jLZWw0ulbno9Z0pmSfkmAZ1OBG4En9AIeI0WTdy5g3 Rv+LJ8E7hFpuvEkBqH5S55vKkZywgyOVS+rC74+OeLaRPSv90hyCvaDsYAPh2b3RXi6d Uk9LmzhRQcqWOHVcIAvb8U5xdODgbx++guq9z8hZCQLwpi2fxaR3Pa0zb4zJTRr4nQBu ch94bPJCshUX0VGkn2VVpF00yY49CTY4qLBTTme2Fe6DVP/swols6c3/hcY18xpWcfV5 wReY+cIBlLphq9aMrdvQPzrTa7zSjSfS7GeOhdSiXa5boMqs5lz7I83cwJGr1OeoZ+49 D53g== X-Gm-Message-State: APjAAAWQNlDg4CDVHQG6/wpwoAx9XTPquuEzDLSL6hGITbom68gTcg82 TCmZN7xFGvuLM2AFsnLz3z9fN540iKIRBqKSQ/IJJg== X-Received: by 2002:a05:6638:308:: with SMTP id w8mr834479jap.75.1568651680894; Mon, 16 Sep 2019 09:34:40 -0700 (PDT) MIME-Version: 1.0 References: <20190916162258.6528-1-vkuznets@redhat.com> <20190916162258.6528-3-vkuznets@redhat.com> In-Reply-To: <20190916162258.6528-3-vkuznets@redhat.com> From: Jim Mattson Date: Mon, 16 Sep 2019 09:34:29 -0700 Message-ID: Subject: Re: [PATCH 2/3] KVM: x86: hyper-v: set NoNonArchitecturalCoreSharing CPUID bit when SMT is impossible To: Vitaly Kuznetsov Cc: kvm list , LKML , linux-hyperv@vger.kernel.org, "the arch/x86 maintainers" , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Sean Christopherson , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "Peter Zijlstra (Intel)" , Michael Kelley , Roman Kagan Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 16, 2019 at 9:23 AM Vitaly Kuznetsov wrote: > > Hyper-V 2019 doesn't expose MD_CLEAR CPUID bit to guests when it cannot > guarantee that two virtual processors won't end up running on sibling SMT > threads without knowing about it. This is done as an optimization as in > this case there is nothing the guest can do to protect itself against MDS > and issuing additional flush requests is just pointless. On bare metal the > topology is known, however, when Hyper-V is running nested (e.g. on top of > KVM) it needs an additional piece of information: a confirmation that the > exposed topology (wrt vCPU placement on different SMT threads) is > trustworthy. > > NoNonArchitecturalCoreSharing (CPUID 0x40000004 EAX bit 18) is described in > TLFS as follows: "Indicates that a virtual processor will never share a > physical core with another virtual processor, except for virtual processors > that are reported as sibling SMT threads." From KVM we can give such > guarantee in two cases: > - SMT is unsupported or forcefully disabled (just 'disabled' doesn't work > as it can become re-enabled during the lifetime of the guest). > - vCPUs are properly pinned so the scheduler won't put them on sibling > SMT threads (when they're not reported as such). That's a nice bit of information. Have you considered a mechanism for communicating this information to kvm guests in a way that doesn't require Hyper-V enlightenments? > This patch reports NoNonArchitecturalCoreSharing bit in to userspace in the > first case. The second case is outside of KVM's domain of responsibility > (as vCPU pinning is actually done by someone who manages KVM's userspace - > e.g. libvirt pinning QEMU threads). > > Signed-off-by: Vitaly Kuznetsov > --- > arch/x86/include/asm/hyperv-tlfs.h | 7 +++++++ > arch/x86/kvm/hyperv.c | 4 +++- > 2 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h > index af78cd72b8f3..989a1efe7f5e 100644 > --- a/arch/x86/include/asm/hyperv-tlfs.h > +++ b/arch/x86/include/asm/hyperv-tlfs.h > @@ -170,6 +170,13 @@ > /* Recommend using enlightened VMCS */ > #define HV_X64_ENLIGHTENED_VMCS_RECOMMENDED BIT(14) > > +/* > + * Virtual processor will never share a physical core with another virtual > + * processor, except for virtual processors that are reported as sibling SMT > + * threads. > + */ > +#define HV_X64_NO_NONARCH_CORESHARING BIT(18) > + > /* Nested features. These are HYPERV_CPUID_NESTED_FEATURES.EAX bits. */ > #define HV_X64_NESTED_GUEST_MAPPING_FLUSH BIT(18) > #define HV_X64_NESTED_MSR_BITMAP BIT(19) > diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c > index fff790a3f4ee..9c187d16a9cd 100644 > --- a/arch/x86/kvm/hyperv.c > +++ b/arch/x86/kvm/hyperv.c > @@ -23,6 +23,7 @@ > #include "ioapic.h" > #include "hyperv.h" > > +#include > #include > #include > #include > @@ -1864,7 +1865,8 @@ int kvm_vcpu_ioctl_get_hv_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid2 *cpuid, > ent->eax |= HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED; > if (evmcs_ver) > ent->eax |= HV_X64_ENLIGHTENED_VMCS_RECOMMENDED; > - > + if (!cpu_smt_possible()) > + ent->eax |= HV_X64_NO_NONARCH_CORESHARING; > /* > * Default number of spinlock retry attempts, matches > * HyperV 2016. > -- > 2.20.1 >