Re: [PATCH 02/22] x86/srso: Set CPUID feature bits independently of bug or mitigation status

[Andrew Cooper]

On 23/08/2023 6:20 am, Borislav Petkov wrote:
> On Mon, Aug 21, 2023 at 04:06:19PM +0200, Borislav Petkov wrote:
>> And I still don't know what exactly we're going to support when Linux
>> runs as a guest. For example, live migration between Zen1/2 and Zen3/4
>> won't work due to the alternatives patching, for example...
>>
>> IBPB won't work either because we detect those feature bits only once
>> during boot, like every other feature bit...
> The lowest common denominator of features exposed to the guests,

Correct.  This is what a hypervisor will do for the SBPB *CPUID* bit.

> should
> work, as I'm being told. As in, Zen2 and Zen3 should hide the SBPB bit
> from the guests, for example.

In my previous reply, I explained why this goes wrong when Linux ignores
the CPUID bit provided by the hypervisor and decides to probe manually.

> I'm thinking if anyone cares really deeply about live migration, anyone
> should say so and then we can see what cases we can support upstream. My
> guess is those who do, have enough engineers to patch their kernel the
> way they want it...

No.

You don't get to take my code, break it when integrating it into Linux,
then dismiss the bug as something hypothetical that you don't want to fix.

It's not *me* needing to patch *my* kernel when this goes wrong.  It's
me (or VMware, or HyperV or one of many KVM vendors) getting a bug
report saying "my VM crashed on migrate", and then having to persuade
Debian and Ubuntu and RH and Oracle and all the other distros to take an
out-of-tree fix into their patchqueue, then release another kernel, and
then come back to this thread and repeat this damn argument.

I'm just trying to cutting out the middle misery here.

~Andrew