From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S932652AbcKGRHZ (ORCPT <rfc822;w@1wt.eu>);
        Mon, 7 Nov 2016 12:07:25 -0500
Received: from mail.skyhub.de ([78.46.96.112]:35101 "EHLO mail.skyhub.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752534AbcKGRHW (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 7 Nov 2016 12:07:22 -0500
Date: Mon, 7 Nov 2016 18:07:20 +0100
From: Borislav Petkov <bp@alien8.de>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: He Chen <he.chen@linux.intel.com>, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, x86@kernel.org,
        Paolo Bonzini <pbonzini@redhat.com>,
        Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
        Luwei Kang <luwei.kang@intel.com>, Piotr Luc <Piotr.Luc@intel.com>
Subject: Re: [PATCH v3] x86/cpuid: expose AVX512_4VNNIW and AVX512_4FMAPS
 features to kvm guest
Message-ID: <20161107170720.drgqul4oc3yzcqff@pd.tnic>
References: <1478243239-15586-1-git-send-email-he.chen@linux.intel.com>
 <20161104105235.qbqvmsv4ikajvjtu@pd.tnic>
 <20161107021007.GA28372@he>
 <20161107090504.f5didblo3p7xz5wg@pd.tnic>
 <alpine.DEB.2.20.1611071738480.3709@nanos>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.20.1611071738480.3709@nanos>
User-Agent: NeoMutt/20161014 (1.7.1)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.