historical-speck.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 1/2] v3 more sampling fun 1
Date: Wed, 11 Mar 2020 17:25:21 -0700	[thread overview]
Message-ID: <20200312002521.GA32316@agluck-desk2.amr.corp.intel.com> (raw)
In-Reply-To: <20200311231819.GB78230@mtg-dev.jf.intel.com>

On Wed, Mar 11, 2020 at 04:18:19PM -0700, speck for mark gross wrote:
> On Wed, Mar 11, 2020 at 08:28:36PM +0000, speck for Andrew Cooper wrote:
> > On 16/01/2020 22:16, speck for mark gross wrote:
> > > +static void __init srbds_select_mitigation(void)
> > > +{
> > > +	u64 ia32_cap;
> > > +
> > > +	if (!boot_cpu_has_bug(X86_BUG_SRBDS)) {
> > > +		srbds_mitigation = SRBDS_NOT_AFFECTED;
> > > +		return;
> > > +	}
> > > +
> > > +	if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
> > > +		srbds_mitigation = SRBDS_HYPERVISOR;
> > > +		return;
> > > +	}
> > 
> > These two ought to be reversing (and with a suitable adjustment to the
> > docs in patch 2).
> > 
> > If you're running as a guest, you can't even trust the model number used
> > to divine X86_BUG_SRBDS in the first place.
> > 
> 
> I'll change this for the next version.

Andrew: Are you really sure that you want that? It would
mean that all guests running on any server level Xeon
would report mitigation status as unknown. Actually
all those server Xeons are not affected by SRBDS.

Technically that is entirely the right thing to do. But
how much do hypervisors mess with the CPU model between
different classes on processors in practice? I thought
that commonly people put a bunch of Haswell/Broadwell/Skylakes
into a "pool" and pretended they were all Haswell.

Do you want to consider the tradeoff between being
absolutely accurate against all the support calls
you will get because guests report "unknown" mitigation
status?

-Tony

  reply	other threads:[~2020-03-12  0:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11 15:39 [MODERATED] [PATCH 0/2] v3 more sampling fun 0 mark gross
2020-01-16 22:16 ` [MODERATED] [PATCH 1/2] v3 more sampling fun 1 mark gross
2020-01-30 19:12 ` [MODERATED] [PATCH 2/2] v3 more sampling fun 2 mark gross
     [not found] ` <5e690bea.1c69fb81.16d6d.4b78SMTPIN_ADDED_BROKEN@mx.google.com>
2020-03-11 17:21   ` [MODERATED] Re: [PATCH 1/2] v3 more sampling fun 1 Greg KH
2020-03-11 23:09     ` mark gross
2020-03-11 20:02 ` Thomas Gleixner
2020-03-17 18:56   ` [MODERATED] " mark gross
2020-03-11 20:26 ` [PATCH 2/2] v3 more sampling fun 2 Thomas Gleixner
2020-03-11 20:38   ` [MODERATED] " Andrew Cooper
2020-03-11 23:23   ` mark gross
2020-03-12 22:04   ` mark gross
2020-03-13 15:21     ` Thomas Gleixner
2020-03-11 20:28 ` [MODERATED] Re: [PATCH 1/2] v3 more sampling fun 1 Andrew Cooper
2020-03-11 23:18   ` mark gross
2020-03-12  0:25     ` Luck, Tony [this message]
2020-03-12  1:34       ` Andrew Cooper
2020-03-12 15:25         ` Luck, Tony
2020-03-12 16:02           ` Luck, Tony
2020-03-12 16:45             ` Andrew Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200312002521.GA32316@agluck-desk2.amr.corp.intel.com \
    --to=tony.luck@intel.com \
    --cc=speck@linutronix.de \
    --subject='[MODERATED] Re: [PATCH 1/2] v3 more sampling fun 1' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).