linux-kernel - Re: [PATCH v3] x86/cpuid: expose AVX512_4VNNIW and AVX512

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 7 Nov 2016 18:07:20 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     He Chen <he.chen@...ux.intel.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Ingo Molnar <mingo@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Luwei Kang <luwei.kang@...el.com>,
        Piotr Luc <Piotr.Luc@...el.com>
Subject: Re: [PATCH v3] x86/cpuid: expose AVX512_4VNNIW and AVX512_4FMAPS
 features to kvm guest

On Mon, Nov 07, 2016 at 05:47:21PM +0100, Thomas Gleixner wrote:
> How do you make that struct definition static?

Not make it static - rename it. Sorry.

It is used only locally in that file anyway.

> Both the enum and the struct should be in processor.h obviously with
> different names so we won't trip over this once more. And the obvious
> naming is:
> 
> struct cpuid_regs {
>       u32 eax, ebx, ecx, edx;
> };
> 
> enum cpuid_regs_idx {
>      CPUID_EAX,
>      CPUID_EBX,
>      CPUID_ECX,
>      CPUID_EDX,
> };
> 
> as CR_E*X is just not intuitive at all.

Ok, that makes sense.

Also, grepping around the tree - we don't have one definitive enum
containing all the architectural registers and maybe we should have one.
We do have some PT_E*X ptrace definitions and others in entry*.S, and...

We probably should have something like:

enum regs {
        AX = 0,
        CX,
        DX,
        BX,
        SP,
        BP,
        SI,
        DI,
        R8,
        R9,
        R10,
        R11,
        R12,
        R13,
        R14,
        R15
};

in the exactly same order as they're encoded in the x86 opcodes.

Yeah, I don't see a pressing reason for that yet though but maybe
we should think about it. My angle is, avoid confusion and ad-hoc
definitions spreading around the code.

Thanks.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.