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

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

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Thu, 2020-02-06 at 14:11 -0800, speck for mark gross wrote:
> From: mark gross <mgross@linux.intel.com>
> Subject: [PATCH 1/2] Add capability to specify a range of steppings in the
[...]
> --- a/arch/x86/include/asm/cpu_device_id.h
> +++ b/arch/x86/include/asm/cpu_device_id.h
> @@ -35,7 +35,19 @@ struct x86_cpu_desc {
>  	.x86_microcode_rev	= (revision),			\
>  }
>  
> +/*
> + * Match a range of steppings
> + */
> +
> +struct x86_cpu_id_ext {
> +	struct x86_cpu_id id;
> +	__u16 steppings; /* bit map of steppings to match against */
> +};
> +
> +#define X86_STEPPING_ANY 0
[...]

Minor point, but wouldn't it make more sense to define X86_STEPPING_ANY
as GENMASK(15, 0)?  Then it's no longer a special case.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[mark gross]

On Thu, Feb 20, 2020 at 07:08:45PM +0000, speck for Ben Hutchings wrote:
> On Thu, 2020-02-06 at 14:11 -0800, speck for mark gross wrote:
> > From: mark gross <mgross@linux.intel.com>
> > Subject: [PATCH 1/2] Add capability to specify a range of steppings in the
> [...]
> > --- a/arch/x86/include/asm/cpu_device_id.h
> > +++ b/arch/x86/include/asm/cpu_device_id.h
> > @@ -35,7 +35,19 @@ struct x86_cpu_desc {
> >  	.x86_microcode_rev	= (revision),			\
> >  }
> >  
> > +/*
> > + * Match a range of steppings
> > + */
> > +
> > +struct x86_cpu_id_ext {
> > +	struct x86_cpu_id id;
> > +	__u16 steppings; /* bit map of steppings to match against */
> > +};
> > +
> > +#define X86_STEPPING_ANY 0
> [...]
> 
> Minor point, but wouldn't it make more sense to define X86_STEPPING_ANY
> as GENMASK(15, 0)?  Then it's no longer a special case.
> 
Right, I had initialy used basicaly the equivelent (-1 or 0xFFFF) for
X86_STEPPING_ANY but, it was pointed out that other similar usages use 0 as a
flag for "ANY" and was encuraged to mimic that logic.  See X86_FAMILY_ANY,
X86_MODEL_ANY, X86_FEATURE_ANY.

I'm cool with either way.

Given this background do you still encurage using GENMASK(15,0)?

--mark

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

[Borislav Petkov]

On Thu, Feb 06, 2020 at 02:11:02PM -0800, speck for mark gross wrote:
> From: mark gross <mgross@linux.intel.com>
> Subject: [PATCH 1/2] Add capability to specify a range of steppings in the
> 
> Intel has produced processors with the same CPUID family+model. Code
> may need to check the stepping when programming model specific behavior.
> 
> Add an API to allow easy specification of stepping or range of steppings
> with a 16 bit bitmask.
> 
> Update cpu_vuln_whitelist using this new API.
> 
> I implemented this in the way I did to avoid modifying x86_cpu_id as
> that structure is an exported ABI and any change would impact user mode
> code using the structure.
> 
> Signed-off-by: mark gross <mgross@linux.intel.com>
> Reviewed-by: tony luck <tony.luck@intel.com>
> ---
>  arch/x86/include/asm/cpu_device_id.h | 12 ++++++++++++
>  arch/x86/kernel/cpu/common.c         | 28 ++++++++++++++--------------
>  arch/x86/kernel/cpu/match.c          | 26 ++++++++++++++++++++++++++
>  3 files changed, 52 insertions(+), 14 deletions(-)

Why isn't this sent to lkml like a normal patch?

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
-- 

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

[Andrew Cooper]

[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]

On 20/02/2020 10:07, speck for Borislav Petkov wrote:
> On Thu, Feb 06, 2020 at 02:11:02PM -0800, speck for mark gross wrote:
>> From: mark gross <mgross@linux.intel.com>
>> Subject: [PATCH 1/2] Add capability to specify a range of steppings in the
>>
>> Intel has produced processors with the same CPUID family+model. Code
>> may need to check the stepping when programming model specific behavior.
>>
>> Add an API to allow easy specification of stepping or range of steppings
>> with a 16 bit bitmask.
>>
>> Update cpu_vuln_whitelist using this new API.
>>
>> I implemented this in the way I did to avoid modifying x86_cpu_id as
>> that structure is an exported ABI and any change would impact user mode
>> code using the structure.
>>
>> Signed-off-by: mark gross <mgross@linux.intel.com>
>> Reviewed-by: tony luck <tony.luck@intel.com>
>> ---
>>  arch/x86/include/asm/cpu_device_id.h | 12 ++++++++++++
>>  arch/x86/kernel/cpu/common.c         | 28 ++++++++++++++--------------
>>  arch/x86/kernel/cpu/match.c          | 26 ++++++++++++++++++++++++++
>>  3 files changed, 52 insertions(+), 14 deletions(-)
> Why isn't this sent to lkml like a normal patch?
>

Because it is under embargo until May 12th.

~Andrew

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

[Borislav Petkov]

On Thu, Feb 20, 2020 at 10:10:03AM +0000, speck for Andrew Cooper wrote:
> Because it is under embargo until May 12th.

Maybe 2/2 is - which I don't have in my mbox - but by staring only at
1/2 there's nothing to embargo there AFAICT.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
-- 

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

[Andrew Cooper]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

On 20/02/2020 10:13, speck for Borislav Petkov wrote:
> On Thu, Feb 20, 2020 at 10:10:03AM +0000, speck for Andrew Cooper wrote:
>> Because it is under embargo until May 12th.
> Maybe 2/2 is - which I don't have in my mbox - but by staring only at
> 1/2 there's nothing to embargo there AFAICT.
>

Right, but a lone patch (coming pre-reviewed even!) adding stepping
support into the speculative model checking is going to be about as
subtle as the KPTI work was :)

~Andrew

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

[Greg KH]

On Thu, Feb 20, 2020 at 11:00:40AM +0000, speck for Andrew Cooper wrote:
> On 20/02/2020 10:13, speck for Borislav Petkov wrote:
> > On Thu, Feb 20, 2020 at 10:10:03AM +0000, speck for Andrew Cooper wrote:
> >> Because it is under embargo until May 12th.
> > Maybe 2/2 is - which I don't have in my mbox - but by staring only at
> > 1/2 there's nothing to embargo there AFAICT.
> >
> 
> Right, but a lone patch (coming pre-reviewed even!) adding stepping
> support into the speculative model checking is going to be about as
> subtle as the KPTI work was :)

Don't pre-review it then.  Just submit it like any other normal cleanup
patch.

thanks,

greg k-h

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

[mark gross]

On Thu, Feb 20, 2020 at 11:07:45AM +0100, speck for Borislav Petkov wrote:
> On Thu, Feb 06, 2020 at 02:11:02PM -0800, speck for mark gross wrote:
> > From: mark gross <mgross@linux.intel.com>
> > Subject: [PATCH 1/2] Add capability to specify a range of steppings in the
> > 
> > Intel has produced processors with the same CPUID family+model. Code
> > may need to check the stepping when programming model specific behavior.
> > 
> > Add an API to allow easy specification of stepping or range of steppings
> > with a 16 bit bitmask.
> > 
> > Update cpu_vuln_whitelist using this new API.
> > 
> > I implemented this in the way I did to avoid modifying x86_cpu_id as
> > that structure is an exported ABI and any change would impact user mode
> > code using the structure.
> > 
> > Signed-off-by: mark gross <mgross@linux.intel.com>
> > Reviewed-by: tony luck <tony.luck@intel.com>
> > ---
> >  arch/x86/include/asm/cpu_device_id.h | 12 ++++++++++++
> >  arch/x86/kernel/cpu/common.c         | 28 ++++++++++++++--------------
> >  arch/x86/kernel/cpu/match.c          | 26 ++++++++++++++++++++++++++
> >  3 files changed, 52 insertions(+), 14 deletions(-)
> 
> Why isn't this sent to lkml like a normal patch?
Because its only needed in the context of the WIP mitigation patch that I'm
having issues sending propperly.

Sigh, I guess I'll just put it in a reply.

--mark

> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
> -- 

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

[Borislav Petkov]

On Thu, Feb 20, 2020 at 09:53:40AM -0800, speck for mark gross wrote:
> Because its only needed in the context of the WIP mitigation patch that I'm
> having issues sending propperly.
> 
> Sigh, I guess I'll just put it in a reply.

Actually, your 2/2 was being held by the ML because you've sent,
reportedly, not from the mail address you're subscribed with, to speck@.
It should be fixed now because Thomas added an alias for your other mail
address.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
-- 

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

[mark gross]

On Thu, Feb 20, 2020 at 07:26:46PM +0100, speck for Borislav Petkov wrote:
> On Thu, Feb 20, 2020 at 09:53:40AM -0800, speck for mark gross wrote:
> > Because its only needed in the context of the WIP mitigation patch that I'm
> > having issues sending propperly.
> > 
> > Sigh, I guess I'll just put it in a reply.
> 
> Actually, your 2/2 was being held by the ML because you've sent,
> reportedly, not from the mail address you're subscribed with, to speck@.
> It should be fixed now because Thomas added an alias for your other mail
> address.

I have moved my work to a different workstation recently.... I'll look into
this.

Thanks, 

--mark

> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
> -- 

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

[mark gross]

On Thu, Feb 20, 2020 at 07:26:46PM +0100, speck for Borislav Petkov wrote:
> On Thu, Feb 20, 2020 at 09:53:40AM -0800, speck for mark gross wrote:
> > Because its only needed in the context of the WIP mitigation patch that I'm
> > having issues sending propperly.
> > 
> > Sigh, I guess I'll just put it in a reply.
> 
> Actually, your 2/2 was being held by the ML because you've sent,
> reportedly, not from the mail address you're subscribed with, to speck@.
> It should be fixed now because Thomas added an alias for your other mail
> address.
>
Fixed my .gitconfig to use mgross@linux.intel.com FWIW I plan to post an update
Monday rebased to rc3.

--mark