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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 20 Feb 2019 01:10:04 -0500 From: Len Brown <lenb@...nel.org> To: Like Xu <like.xu@...ux.intel.com> Cc: X86 ML <x86@...nel.org>, linux-kernel@...r.kernel.org, Len Brown <len.brown@...el.com>, linux-doc@...r.kernel.org Subject: Re: [PATCH 03/11] x86 topology: Add CPUID.1F multi-die/package support On Tue, Feb 19, 2019 at 9:59 PM Like Xu <like.xu@...ux.intel.com> wrote: > > -/* leaf 0xb sub-leaf types */ > > +/* extended topology sub-leaf types */ > > #define INVALID_TYPE 0 > > #define SMT_TYPE 1 > > #define CORE_TYPE 2 > > +#define DIE_TYPE 5 > > This patch set is going to export die topology via sysfs > while the extended topology sub-leaf type could be one of followings: > SMT/Core/Module/Tile/Die according to CPUID.1F from SDM. > > Why not choose to export module/tile topology as well? Excellent question. (and thank you for reading the SDM:-) While it is true that there are shipping products with software-visible CPU modules and tiles, they shipped before this mechanism was available. As a result, there are currently zero products that use this mechanism to enumerate modules and tiles. If future products have software-visible modules and tiles, and they choose to use this mechanism, we can add support for them. But I do not advocate adding code to the kernel "just in case". In contrast, the need to support multi-die/package products as soon as possible is quite clear. thanks, Len Brown, Intel Open Source Technology Center
Powered by blists - more mailing lists