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:   Tue, 7 Mar 2023 15:35:20 -0800
From:   Sean Christopherson <seanjc@...gle.com>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     Tom Lendacky <thomas.lendacky@....com>,
        Usama Arif <usama.arif@...edance.com>, tglx@...utronix.de,
        kim.phillips@....com, brgerst@...il.com,
        Sabin Rapan <sabrapan@...zon.com>, piotrgorski@...hyos.org,
        oleksandr@...alenko.name, arjan@...ux.intel.com, mingo@...hat.com,
        bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com,
        x86@...nel.org, pbonzini@...hat.com, paulmck@...nel.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        rcu@...r.kernel.org, mimoja@...oja.de, hewenliang4@...wei.com,
        pmenzel@...gen.mpg.de, fam.zheng@...edance.com,
        punit.agrawal@...edance.com, simon.evans@...edance.com,
        liangma@...ngbit.com
Subject: Re: [PATCH v13 00/11] Parallel CPU bringup for x86_64

On Tue, Mar 07, 2023, David Woodhouse wrote:
> On Tue, 2023-03-07 at 16:22 -0600, Tom Lendacky wrote:
> > 
> > I did some Qemu/KVM testing. One thing I noticed is that on AMD, CPUID 0xB 
> > EAX will be non-zero only if SMT is enabled. So just booting some guests 
> > without CPU topology never did parallel booting ("smpboot: Disabling 
> > parallel bringup because CPUID 0xb looks untrustworthy"). I would imagine 
> > a bare-metal system that has diabled SMT will not do parallel booting, too 
> > (but I haven't had time to test that).
> 
> Interesting, thanks. Should I change to checking for *both* EAX and EBX
> being zero? That's what I did first, after reading only the Intel SDM.
> But I changed to only EAX because the AMD doc only says that EAX will
> be zero for unsupported leaves.

LOL, nice.  '0' is a prefectly valid output for the shift if there's exactly one
CPU at the current level, which is why Intel states that both EAX and EBX are
cleared.  I assume/hope this is effectively a documentation goof, in that the APM
assumes that all "real" CPUs that support CPUID 0xB also support sub-function 0.

Nit, the AMD says EAX will be zero for unsupported _levels_.  The distinction
matters because if the entire leaf is unsupported, AMD behavior is to zero out
all output registers, even if the input leaf is above the max supported leaf.

Anyways, the kernel already sanity checks the outputs on all x86 CPUs, just
piggyback that logic, e.g. expose detect_extended_topology_leaf() or so.  If AMD
or a VMM is doing something crazy, the kernel is doomed anyways.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ