[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zg94la7l.ffs@tglx>
Date: Thu, 23 Feb 2023 15:37:02 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: David Woodhouse <dwmw2@...radead.org>,
Usama Arif <usama.arif@...edance.com>, kim.phillips@....com
Cc: 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,
thomas.lendacky@....com, seanjc@...gle.com, pmenzel@...gen.mpg.de,
fam.zheng@...edance.com, punit.agrawal@...edance.com,
simon.evans@...edance.com, liangma@...ngbit.com,
Ashok Raj <ashok.raj@...el.com>
Subject: Re: [PATCH v9 0/8] Parallel CPU bringup for x86_64
David!
On Thu, Feb 23 2023 at 11:07, David Woodhouse wrote:
> On Wed, 2023-02-22 at 17:42 +0100, Thomas Gleixner wrote:
>> The low hanging fruit which brings most is the identification/topology
>> muck and the microcode loading. That needs to be addressed first anyway.
>
> Agreed, thanks.
So the problem with microcode loading is that we must ensure that a HT
sibling is not executing anything else than a trivial loop waiting for
the update to complete. So something like this should work:
1) Kick all CPUs into life and let them run up to cpu_init() and
retrieve only the topology information.
2) Wait for all CPUs to reach this point
3) Release all primary HT threads so they can load microcode in
parallel. The secondary HT threads stay in the wait loop and are
released once the primary thread has finished the microcode
update.
4) Let the CPUs do the full CPUID readout and let them synchronize
with the control CPU again.
5) Complete bringup one by one
Thanks,
tglx
Powered by blists - more mailing lists