Re: [PATCH v3 2/6] x86/bugs: Use SBPB in __write_ibpb() if applicable

[Jim Mattson]

On Wed, Apr 2, 2025 at 7:18 PM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
>
> On Wed, Apr 02, 2025 at 02:04:04PM -0700, Jim Mattson wrote:
> > On Wed, Apr 2, 2025 at 11:20 AM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
> > >
> > > __write_ibpb() does IBPB, which (among other things) flushes branch type
> > > predictions on AMD.  If the CPU has SRSO_NO, or if the SRSO mitigation
> > > has been disabled, branch type flushing isn't needed, in which case the
> > > lighter-weight SBPB can be used.
> >
> > When nested SVM is not supported, should KVM "promote"
> > SRSO_USER_KERNEL_NO on the host to SRSO_NO in KVM_GET_SUPPORTED_CPUID?
> > Or is a Linux guest clever enough to do the promotion itself if
> > CPUID.80000001H:ECX.SVM[bit 2] is clear?
>
> I'm afraid that question is beyond my pay grade, maybe some AMD or virt
> folks can chime in.

That question aside, I'm not sure that this series is safe with
respect to nested virtualization.

If the CPU has SRSO_NO, then KVM will report SRSO_NO in
KVM_GET_SUPPORTED_CPUID. However, in nested virtualization, the L1
guest and the L2 guest share a prediction domain. KVM currently
ensures isolation between L1 and L2 with a call to
indirect_branch_prediction_barrier() in svm_vcpu_load(). I think that
particular barrier should *always* be a full IBPB--even if the host
has SRSO_NO.