[MODERATED] Re: [PATCH 1/2] v3 more sampling fun 1

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