Re: [PATCH v2 0/4] x86/mtrr: Allow MTRR updates on multiple CPUs in parallel

[Jürgen Groß]

On 12.03.26 22:33, Dave Hansen wrote:
> On 3/11/26 02:08, Juergen Gross wrote:
> > Any real reason not to take this patch series?
>
> Uhh, it has zero review comments on it. That's usually a pretty good reason.
>
> It is a little worrying that this is even happening. Is there just a
> single blip during boot when the MTRRs are "corrected" and then it's
> never a problem again? Or is it causing latency blips all the time?

The machine having the lockups has been verified to have inconsistent
initial MTRR values, so the APs (at least some of them) need to update
their MTRR registers during boot.

BUT: I believe that the same could happen in case some device driver needs
to set some MTRR registers when adding a device. The code will do the same
as during boot: all CPUs need to do the update of the MTRR(s) using
stop_machine_cpuslocked(), which will serialize the updates across the CPUs.
With enough CPUs on the machine time will sum up again.

> I do share some of Peter's concern that this is creaky, fragile,
> lightly-used code and this series is mucking with it to work around a
> BIOS issue.

The real change on each CPU is just the drop of global variable use and the
drop of the lock. MTRR handling itself on each CPU isn't modified.

Additionally there is even a comment in today's code that doing only one
CPU at a time is not an optimal solution and that doing all CPUs at the same
time would be the preferred way to handle it.

In case you are really worried that updating all CPUs in parallel might be
problematic in rare cases, I could be talked into making the lock optional
(defaulting to not using it) and controllable via a boot parameter.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature