On Wed, Sep 02, 2020 at 05:40:18PM +0200, Borislav Petkov wrote:
> On Thu, Aug 27, 2020 at 03:49:03PM +0800, Feng Tang wrote:
> > output of the tool
> > --
> >
> > CPUID leafs total: 28
> >
> > cpu family : 6
> > model : 13
> > stepping: 7
>
On Wed, Sep 02, 2020 at 10:18:38AM -0700, Dave Hansen wrote:
> All good points.
>
> Personally, I think I'd be OK if kcpuid _focused_ on single-bit values
> only. Those are the vast majority of the things that we need from such
> a tool. I don't think there's nearly as much demand for the
On 9/2/20 9:52 AM, Borislav Petkov wrote:
>> I was *really* hoping that we could eventually feed kcpuid and the
>> X86_FEATURE_* bits from the same source.
> But X86_FEATURE_* won't be all bits in all CPUID leafs - only the ones the
> kernel has enabled/use for/needs/...
>
> Also you have CPUID
On Wed, Sep 02, 2020 at 06:55:01PM +0200, Borislav Petkov wrote:
> On Wed, Sep 02, 2020 at 06:45:38PM +0200, pet...@infradead.org wrote:
> > We really should clear the CPUID bits when the kernel explicitly
> > disables things.
>
> Actually, you want to *disable* the functionality behind it by
On Wed, Sep 02, 2020 at 09:52:33AM -0700, Dave Hansen wrote:
> On 9/2/20 9:45 AM, pet...@infradead.org wrote:
> > On Thu, Aug 27, 2020 at 03:49:03PM +0800, Feng Tang wrote:
> >> End users frequently want to know what features their processor
> >> supports, independent of what the kernel supports.
On Wed, Sep 02, 2020 at 06:45:38PM +0200, pet...@infradead.org wrote:
> We really should clear the CPUID bits when the kernel explicitly
> disables things.
Actually, you want to *disable* the functionality behind it by clearing
a bit in CR4 - and yes, not all features have CR4 bits - so that
On Wed, Sep 02, 2020 at 09:25:17AM -0700, Dave Hansen wrote:
> Ugh. I hate text parsers. But, I do see what you're getting at.
That's why it'll be a simple one. Nothing fancy. I'm hoping the final
version would be somewhat readable to humans too.
> If we do this, I bet having each value on its
On 9/2/20 9:45 AM, pet...@infradead.org wrote:
> On Thu, Aug 27, 2020 at 03:49:03PM +0800, Feng Tang wrote:
>> End users frequently want to know what features their processor
>> supports, independent of what the kernel supports.
>>
>> /proc/cpuinfo is great. It is omnipresent and since it is
On Thu, Aug 27, 2020 at 03:49:03PM +0800, Feng Tang wrote:
> End users frequently want to know what features their processor
> supports, independent of what the kernel supports.
>
> /proc/cpuinfo is great. It is omnipresent and since it is provided by
> the kernel it is always as up to date as
On 9/2/20 8:40 AM, Borislav Petkov wrote:
> When you need to add a new leaf, you simply extend the text file and the
> tool parses it anew and has its all CPUID info uptodate. This way you
> won't even have to recompile it. Adding new CPUID leafs would be adding new
> lines to the file.
>
> For
On Thu, Aug 27, 2020 at 03:49:03PM +0800, Feng Tang wrote:
> output of the tool
> --
>
> CPUID leafs total: 28
>
> cpu family : 6
> model : 13
> stepping: 7
Yeah, this should dump model etc and those numbers should be in hex and
End users frequently want to know what features their processor
supports, independent of what the kernel supports.
/proc/cpuinfo is great. It is omnipresent and since it is provided by
the kernel it is always as up to date as the kernel. But, it can be
ambiguous about processor features which can
End users frequently want to know what features their processor
supports, independent of what the kernel supports.
/proc/cpuinfo is great. It is omnipresent and since it is provided by
the kernel it is always as up to date as the kernel. But, it can be
ambiguous about processor features which can
13 matches
Mail list logo
