From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Chao Gao <chao.gao@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Alexandre Chartre <alexandre.chartre@oracle.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
x86@kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, daniel.sneddon@linux.intel.com,
pawan.kumar.gupta@linux.intel.com, tglx@linutronix.de,
peterz@infradead.org, gregkh@linuxfoundation.org,
seanjc@google.com, dave.hansen@linux.intel.com,
nik.borisov@suse.com, kpsingh@kernel.org, longman@redhat.com,
bp@alien8.de
Subject: Re: [PATCH] KVM: x86: Set BHI_NO in guest when host is not affected by BHI
Date: Thu, 11 Apr 2024 16:50:12 -0400 [thread overview]
Message-ID: <ZhhNBCtY0rgfJdRK@char.us.oracle.com> (raw)
In-Reply-To: <ZhgIN4LIu2K5vf5y@chao-email>
On Thu, Apr 11, 2024 at 11:56:39PM +0800, Chao Gao wrote:
> On Thu, Apr 11, 2024 at 05:20:30PM +0200, Paolo Bonzini wrote:
> >On Thu, Apr 11, 2024 at 5:13 PM Alexandre Chartre
> ><alexandre.chartre@oracle.com> wrote:
> >> I think that Andrew's concern is that if there is no eIBRS on the host then
> >> we do not set X86_BUG_BHI on the host because we know the kernel which is
> >> running and this kernel has some mitigations (other than the explicit BHI
> >> mitigations) and these mitigations are enough to prevent BHI. But still
> >> the cpu is affected by BHI.
> >
> >Hmm, then I'm confused. It's what I wrote before: "The (Linux or
> >otherwise) guest will make its own determinations as to whether BHI
> >mitigations are necessary. If the guest uses eIBRS, it will run with
> >mitigations" but you said machines without eIBRS are fine.
> >
> >If instead they are only fine _with Linux_, then yeah we cannot set
> >BHI_NO in general. What we can do is define a new bit that is in the
> >KVM leaves. The new bit is effectively !eIBRS, except that it is
> >defined in such a way that, in a mixed migration pool, both eIBRS and
> >the new bit will be 0.
>
> This looks a good solution.
>
> We can also introduce a new bit indicating the effectiveness of the short
> BHB-clearing sequence. KVM advertises this bit for all pre-SPR/ADL parts.
> Only if the bit is 1, guests will use the short BHB-clearing sequence.
> Otherwise guests should use the long sequence. In a mixed migration pool,
> the VMM shouldn't expose the bit to guests.
Is there a link to this 'short BHB-clearing sequence'?
But on your email, should a Skylake guests enable IBRS (or retpoline)
and have the short BHB clearing sequence?
And IceLake/Cascade lake should use eIBRS (or retpoline) and short BHB
clearing sequence?
If we already know all of this why does the hypervisor need to advertise
this to the guest? They can lookup the CPU data to make this determination, no?
I don't actually understand how one could do a mixed migration pool with
the various mitigations one has to engage (or not) based on the host one
is running under.
>
> >
> >Paolo
> >
> >
next prev parent reply other threads:[~2024-04-11 20:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 7:24 [PATCH] KVM: x86: Set BHI_NO in guest when host is not affected by BHI Alexandre Chartre
2024-04-11 7:34 ` Nikolay Borisov
2024-04-11 7:49 ` Alexandre Chartre
2024-04-11 7:51 ` Greg KH
2024-04-11 8:00 ` Alexandre Chartre
2024-04-11 7:51 ` Nikolay Borisov
2024-04-11 8:43 ` Andrew Cooper
2024-04-11 9:33 ` Alexandre Chartre
2024-04-11 9:38 ` Andrew Cooper
2024-04-11 11:14 ` Chao Gao
2024-04-11 13:20 ` Alexandre Chartre
2024-04-15 15:14 ` Alexandre Chartre
2024-04-15 17:17 ` Dave Hansen
2024-04-16 8:41 ` Alexandre Chartre
2024-04-25 20:45 ` Konrad Rzeszutek Wilk
2024-04-11 13:22 ` Paolo Bonzini
2024-04-11 13:32 ` Alexandre Chartre
2024-04-11 14:13 ` Andrew Cooper
2024-04-11 14:33 ` Alexandre Chartre
2024-04-11 14:46 ` Paolo Bonzini
2024-04-11 15:12 ` Alexandre Chartre
2024-04-11 15:20 ` Paolo Bonzini
2024-04-11 15:56 ` Chao Gao
2024-04-11 20:50 ` Konrad Rzeszutek Wilk [this message]
2024-04-12 3:24 ` Chao Gao
2024-04-12 16:33 ` Konrad Rzeszutek Wilk
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=ZhhNBCtY0rgfJdRK@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=alexandre.chartre@oracle.com \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=daniel.sneddon@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=kpsingh@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=nik.borisov@suse.com \
--cc=pawan.kumar.gupta@linux.intel.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