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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 25 Apr 2017 15:18:53 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Denys Vlasenko <dvlasenk@...hat.com>
Cc:     Ingo Molnar <mingo@...hat.com>, Andy Lutomirski <luto@...nel.org>,
        Brian Gerst <brgerst@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "H. Peter Anvin" <hpa@...ux.intel.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86, msr: Better document AMD "tweak MSRs", rename
 MSR_F15H_IC_CFG

On Tue, Apr 25, 2017 at 03:05:41PM +0200, Denys Vlasenko wrote:
> Okay. Propose a naming scheme for these which looks god to you.

MSR_AMD64_LS_CFG  -> MSR_F16H_LS_CFG
MSR_AMD64_DC_CFG  -> MSR_F10H_DC_CFG
MSR_AMD64_BU_CFG2 -> MSR_F10H_BU_CFG2
MSR_AMD64_DE_CFG  -> MSR_F12H_DE_CFG

and please move that last one to msr-index.h while you're at it as we
want to keep all msrs in a single file.

I know, there's a hint not to do that at the beginning of
arch/x86/include/asm/msr-index.h but tip guys prefer all MSRs in one
place.

> A bit problematic:
> 
> MSR C001_1020 is used (mentioned in Rev Guides as a possible way
> to work around an errata) by all Fams starting from K8, except Fam15h.
> 
> MSR C001_1022 is used by K8, 10h, 15h.

Right, so here the logic should be something like this: If a family has
a LS_CFG MSR, then it gets a define with the family in it. If another
family uses the same MSR number, we do:

#define MSR_F16H_LS_CFG			0xc0011020
#define MSR_K8_LS_CFG			MSR_F16H_LS_CFG

to denote exactly that - those two families happen to share the same
MSR. But it is not guaranteed that future families will have that same
one. And if they do, they can define it, if needed.

This way, the code mirrors the situation exactly.

Thanks.

-- 
Regards/Gruss,
    Boris.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ