linux-kernel - RE: [patch V3 27/40] x86/cpu: Provide a sane leaf 0xb/0x1f parser

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]

Message-ID: <MN0PR11MB6010D09FF7C20779B70A3B83E01BA@MN0PR11MB6010.namprd11.prod.outlook.com>
Date:   Fri, 18 Aug 2023 05:01:29 +0000
From:   "Brown, Len" <len.brown@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        "Zhang, Rui" <rui.zhang@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     "Gross, Jurgen" <jgross@...e.com>,
        "mikelley@...rosoft.com" <mikelley@...rosoft.com>,
        "arjan@...ux.intel.com" <arjan@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "ray.huang@....com" <ray.huang@....com>,
        "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
        "Sivanich, Dimitri" <dimitri.sivanich@....com>,
        "wei.liu@...nel.org" <wei.liu@...nel.org>
Subject: RE: [patch V3 27/40] x86/cpu: Provide a sane leaf 0xb/0x1f parser

Hello Thomas,

Thanks for listening.

Discussing further w/ Rui, we realized that is it not possible to future-proof the CPUID.1F code against the insertion of a new Domain at an  unknown level in the hierarchy.  Further, CPUID.1F explicitly documents that we can not count on any numeric relationship between the Domain Type IDs to tell us between what levels of the hierarchy a future Domain may reside.

For this reason, I recommend that we proceed with implementing internal kernel parsing of Domain Type ID 6 (DieGrp).
Even if DieGrp is a temporary name that changes to something else, we can assert that Domain Type ID 6 contains Die.
Thus, on a system with both DieGrp and Die, we know that multiple DieGrp produce multiple Die, rather than the reverse.

If I understand your description correctly, you propose that if a level is not enumerated, that we assume its id is always 0.  I agree this is the right thing to do with Package, and we should continue doing it, because we always have a package.

However, I don't think this is the right direction for the intermediate levels -- for their existence should be able to be used to enumerate the existence of level-specific features, and 0 suggests that those features exist when they may not.

Take for example, module-scope MSRs and counters that do not exist on systems that do not have modules.

We should only have a valid module_id if CPUID.1F has a non-zero shift width for Domain Type ID 3 (module).  Otherwise, we should probably be setting module_id to -1, so that code looking for those module features knows that they don't exist.  If we don't do this, that code will have to check model # (as it historically has) to determine if module-only features exist -- and we've thrown away the value of architectural level enumeration.

The situation for die_id is similar, except that there are no die features that don't already exist as package features when there is just 1 die/package.  Ie. The die-aware code can simply revert to the package code when die_id= -1.

This, of course, raises the question of the sysfs interface for die_id, and whether it should return -1 when there is no Die enumerated, or make that attribute simply not exist when there is no die_id.  Either would probably be an improvement over conjuring up a phony die_id=0 when no Die is actually enumerated.

Thanks,
-Len