From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Babu Moger <babu.moger@amd.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>,
David.Kaplan@amd.com, Nikolay Borisov <nik.borisov@suse.com>,
gregkh@linuxfoundation.org, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 02/22] x86/srso: Set CPUID feature bits independently of bug or mitigation status
Date: Wed, 23 Aug 2023 13:22:34 +0100 [thread overview]
Message-ID: <22eb07b3-6de4-9fc2-fb05-2c7ebe6dc951@citrix.com> (raw)
In-Reply-To: <20230823052007.GBZOWXBymcCUOoMax3@fat_crate.local>
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
next prev parent reply other threads:[~2023-08-23 12:22 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-21 1:18 [PATCH 00/22] SRSO fixes/cleanups Josh Poimboeuf
2023-08-21 1:18 ` [PATCH 01/22] x86/srso: Fix srso_show_state() side effect Josh Poimboeuf
2023-08-21 5:42 ` Nikolay Borisov
2023-08-21 6:04 ` Borislav Petkov
2023-08-21 16:17 ` Josh Poimboeuf
2023-08-22 5:23 ` Borislav Petkov
2023-08-21 1:18 ` [PATCH 02/22] x86/srso: Set CPUID feature bits independently of bug or mitigation status Josh Poimboeuf
2023-08-21 5:42 ` Nikolay Borisov
2023-08-21 9:27 ` Andrew Cooper
2023-08-21 14:06 ` Borislav Petkov
2023-08-23 5:20 ` Borislav Petkov
2023-08-23 12:22 ` Andrew Cooper [this message]
2023-08-24 4:24 ` Borislav Petkov
2023-08-24 22:04 ` Josh Poimboeuf
2023-08-25 6:42 ` Borislav Petkov
2023-08-21 13:59 ` Borislav Petkov
2023-08-21 1:19 ` [PATCH 03/22] KVM: x86: Support IBPB_BRTYPE and SBPB Josh Poimboeuf
2023-08-21 9:34 ` Andrew Cooper
2023-08-21 16:23 ` Josh Poimboeuf
2023-08-21 16:35 ` Sean Christopherson
2023-08-21 16:46 ` Nikolay Borisov
2023-08-21 16:50 ` Sean Christopherson
2023-08-21 17:05 ` Josh Poimboeuf
2023-08-24 16:39 ` Sean Christopherson
2023-08-24 17:07 ` Josh Poimboeuf
2023-08-21 16:49 ` Sean Christopherson
2023-08-21 1:19 ` [PATCH 04/22] x86/srso: Fix SBPB enablement for spec_rstack_overflow=off Josh Poimboeuf
2023-08-21 14:16 ` Borislav Petkov
2023-08-21 16:36 ` Josh Poimboeuf
2023-08-22 5:54 ` Borislav Petkov
2023-08-22 6:07 ` Borislav Petkov
2023-08-22 21:59 ` Josh Poimboeuf
2023-08-23 1:27 ` Borislav Petkov
2023-08-21 1:19 ` [PATCH 05/22] x86/srso: Fix SBPB enablement for mitigations=off Josh Poimboeuf
2023-08-23 5:57 ` Borislav Petkov
2023-08-23 20:55 ` Josh Poimboeuf
2023-08-23 23:02 ` Josh Poimboeuf
2023-08-21 1:19 ` [PATCH 06/22] x86/srso: Print actual mitigation if requested mitigation isn't possible Josh Poimboeuf
2023-08-23 6:06 ` Borislav Petkov
2023-08-21 1:19 ` [PATCH 07/22] x86/srso: Remove default case in srso_select_mitigation() Josh Poimboeuf
2023-08-23 6:18 ` Borislav Petkov
2023-08-21 1:19 ` [PATCH 08/22] x86/srso: Downgrade retbleed IBPB warning to informational message Josh Poimboeuf
2023-08-24 4:43 ` Borislav Petkov
2023-08-21 1:19 ` [PATCH 09/22] x86/srso: Simplify exit paths Josh Poimboeuf
2023-08-21 1:19 ` [PATCH 10/22] x86/srso: Print mitigation for retbleed IBPB case Josh Poimboeuf
2023-08-24 4:48 ` Borislav Petkov
2023-08-24 21:40 ` Josh Poimboeuf
2023-08-21 1:19 ` [PATCH 11/22] x86/srso: Slight simplification Josh Poimboeuf
2023-08-24 4:55 ` Borislav Petkov
2023-08-21 1:19 ` [PATCH 12/22] x86/srso: Remove redundant X86_FEATURE_ENTRY_IBPB check Josh Poimboeuf
2023-08-25 7:09 ` Borislav Petkov
2023-08-21 1:19 ` [PATCH 13/22] x86/srso: Fix vulnerability reporting for missing microcode Josh Poimboeuf
2023-08-25 7:25 ` Borislav Petkov
2023-08-21 1:19 ` [PATCH 14/22] x86/srso: Fix unret validation dependencies Josh Poimboeuf
2023-08-21 1:19 ` [PATCH 15/22] x86/alternatives: Remove faulty optimization Josh Poimboeuf
2023-08-21 1:19 ` [PATCH 16/22] x86/srso: Unexport untraining functions Josh Poimboeuf
2023-08-21 5:50 ` Nikolay Borisov
2023-08-21 1:19 ` [PATCH 17/22] x86/srso: Disentangle rethunk-dependent options Josh Poimboeuf
2023-08-21 1:19 ` [PATCH 18/22] x86/rethunk: Use SYM_CODE_START[_LOCAL]_NOALIGN macros Josh Poimboeuf
2023-08-21 1:19 ` [PATCH 19/22] x86/srso: Improve i-cache locality for alias mitigation Josh Poimboeuf
2023-08-21 1:19 ` [PATCH 20/22] x86/retpoline: Remove .text..__x86.return_thunk section Josh Poimboeuf
2023-08-21 1:19 ` [PATCH 21/22] x86/nospec: Refactor UNTRAIN_RET[_*] Josh Poimboeuf
2023-08-21 1:19 ` [PATCH 22/22] x86/calldepth: Rename __x86_return_skl() to call_depth_return_thunk() Josh Poimboeuf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=22eb07b3-6de4-9fc2-fb05-2c7ebe6dc951@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=David.Kaplan@amd.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=gregkh@linuxfoundation.org \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nik.borisov@suse.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).