From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 27 Mar 2020 19:12:22 -0000 Received: from mga12.intel.com ([192.55.52.136]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jHuOz-0004EC-Ew for speck@linutronix.de; Fri, 27 Mar 2020 20:12:21 +0100 Received: from localhost (mtg-dev.jf.intel.com [10.54.74.10]) by smtp.ostc.intel.com (Postfix) with ESMTP id 2B629636D for ; Fri, 27 Mar 2020 19:12:17 +0000 (UTC) Date: Fri, 27 Mar 2020 12:12:16 -0700 From: mark gross Subject: [MODERATED] Re: [PATCH 2/3] v4 more sampling fun 2 Message-ID: <20200327191216.GA8589@mtg-dev.jf.intel.com> Reply-To: mgross@linux.intel.com References: <20200326031923.d7hwuq65bb7ymw6g@treble> <20200327162041.GA2707@mtg-dev.jf.intel.com> <20200327172356.GA13816@agluck-desk2.amr.corp.intel.com> MIME-Version: 1.0 In-Reply-To: <20200327172356.GA13816@agluck-desk2.amr.corp.intel.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, Mar 27, 2020 at 10:23:56AM -0700, speck for Luck, Tony wrote: > On Fri, Mar 27, 2020 at 09:20:41AM -0700, speck for mark gross wrote: > > On Wed, Mar 25, 2020 at 10:19:23PM -0500, speck for Josh Poimboeuf wrote: > > > > +static void __init srbds_select_mitigation(void) > > > > +{ > > > > + u64 ia32_cap; > > > > + > > > > + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) { > > > > + srbds_mitigation = SRBDS_HYPERVISOR; > > > > + return; > > > > + } > > > > > > It's confusing that this comes before the X86_BUG_SRBDS check. Is that > > > on purpose? > > VM vendors on keybase wanted it so. > > No. They don't want this. It results in all multi-socket servers > (which are not affected by SRBDS) saying the mitigation status is > unknown. > > The preferred order to check is: > > 1) Am I on the affected list? > > 2) Am I running under a hypervisor? > > > Initially Andrew Cooper had asked for the hypervisor check to come > first. But he has since relented. Below is a comment to explain > why it is practially better to check for prescence on the affected > list *before* checking for hypervisor: > > /* > * This test relies on the CPUID values of vendor, family, model, > * stepping which might not reflect the real hardware when we are > * running as a guest. But VMM vendors have asked that we do this > * before the X86_FEATURE_HYPERVISOR test since this provides better > * guidance to users in most real situations. > */ Ok, I'll change it. --mark