linux-kernel - RE: [RFC PATCH] x86/CPU/AMD: Bring back Compute Unit ID

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 1 Feb 2017 21:55:44 +0000
From:   "Ghannam, Yazen" <Yazen.Ghannam@....com>
To:     Borislav Petkov <bp@...en8.de>
CC:     x86-ml <x86@...nel.org>, Yves Dionne <yves.dionne@...il.com>,
        Brice Goglin <Brice.Goglin@...ia.fr>,
        Peter Zijlstra <peterz@...radead.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH] x86/CPU/AMD: Bring back Compute Unit ID

> -----Original Message-----
> From: Borislav Petkov [mailto:bp@...en8.de]
> Sent: Wednesday, February 1, 2017 4:44 PM
> 
> > To get around this we can set cu_id for all TOPOEXT systems, and update
> > cpu_core_id, etc. for SMT enabled systems. This way we can just change
> > cpu_core_id to cu_id in match_smt().
> 
> Ok, so we want to init ->cu_id to something invalid then. -1, for
> example and then do:
> 
> 	if (c->cu_id != -1 && o->cu_id != -1 && (c->cu_id == o->cu_id))
> 		...
> 
> Alternatively, we can define an X86_FEATURE_COMPUTE_UNITS or so
> synthetic bit which we can check.
> 
> One thing I don't want to do is reuse ->cu_id on systems which don't
> have CUs.
> 

Okay, in that case I would prefer to define a synthetic bit. I think it'll be a lot
more clear.

Thanks,
Yazen