[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230412123044.GJZDakdLatRW26J+1k@fat_crate.local>
Date: Wed, 12 Apr 2023 14:30:44 +0200
From: Borislav Petkov <bp@...en8.de>
To: Juergen Gross <jgross@...e.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH v5 08/15] x86/mtrr: have only one set_mtrr() variant
On Sat, Apr 01, 2023 at 08:36:45AM +0200, Juergen Gross wrote:
> Today there are two variants of set_mtrr(): one calling stop_machine()
"... two variants which set MTRRs: set_mtrr() and set_mtrr_cpuslocked(),
first calling ..."
> and one calling stop_machine_cpuslocked().
>
> The first one (set_mtrr()) has only one caller, and this caller is
> always running with only one CPU online and interrupts being off.
Wait, whaaat?
It's only caller is mtrr_restore() and that is part of syscorse ops
which is registered for
"The CPU has no MTRR and seems to not support SMP."
Do you mean that, per chance?
If you do, please explain that properly in the commit message - this is
not a guessing game.
By the looks of that syscore thing, it is needed for the very old MTRR
implementations which weren't SMP (K6, Centaur, Cyrix etc).
Please explain that in the commit message too. It needs to say *why* the
transformation you're doing is ok.
"this caller is always running with only one CPU online" is not nearly
beginning to explain what the situation is.
> Remove the first variant completely and replace the call of it with
> a call of mtrr_if->set().
>
> Rename the second variant set_mtrr_cpuslocked() to set_mtrr() now that
> there is only one variant left.
Those are visible from the diff itself - you don't need to explain what
the patch does but why.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists