Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932652AbcKGRHZ (ORCPT ); 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 ); Mon, 7 Nov 2016 12:07:22 -0500 Date: Mon, 7 Nov 2016 18:07:20 +0100 From: Borislav Petkov To: Thomas Gleixner Cc: He Chen , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= , Ingo Molnar , "H . Peter Anvin" , Luwei Kang , Piotr Luc 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161014 (1.7.1) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1412 Lines: 64 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.