Re: [PATCH v2] KVM: SVM: let alternatives handle the cases when RSB filling is required

[Amit Shah <amit@kernel.org>]

On Tue, 2024-07-16 at 12:10 -0700, Sean Christopherson wrote:
> On Mon, Jul 15, 2024, Amit Shah wrote:
> > On (Mon) 08 Jul 2024 [11:59:45], Sean Christopherson wrote:
> > > On Mon, Jul 01, 2024, David Kaplan wrote:
> > > > > > 

(snipped to what is now emerging as the core of the discussion)


> > Also - reviewers of code will get confused, wondering why this code
> > for AMD exists when the CPU vuln does not.
> > 
> > I get that we want to write defensive code, but this was a very
> > special condition that is unlikely to happen in this part of the
> > code,
> > and also this was missed by the devs and the reviewers.
> 
> Defensive code is only part of it, and a minor part at that.  The
> main "issue" is
> having divergent VM-Enter/VM-Exit code for Intel vs. AMD.  To those
> of us that
> care primarily about virtualization and are only passingly familiar
> with the myriad
> speculation bugs and mitigations, omitting RSB_VMEXIT_LITE _looks_
> wrong.
> 
> To know that the omission is correct, one has to suss out that it's
> (supposed to
> be) impossible for RSB_VMEXIT_LITE to be set on AMD.  And as a KVM
> person, that's
> a detail I don't want to care about.

OK - I get that.  Cognitive overload is a real thing, and the less of
it the better.

Since this isn't a discussion about any AMD bug or implementation
detail, but rather a uniformity in KVM code across different CPU
implementations from different vendors, I prefer someone else code up
the patch to add that uniformity.  I don't have an objection to that.

I can of course offer a comment in this hunk, though, that says AMD
does not have the bug that necessitates VMEXIT_LITE, and that should
help in the meantime.  You've not queued this patch yet, right?  Do you
think it's better I do a v3 with this comment update?

> FWIW, I feel the same way about all the other post-VM-Exit
> mitigations, they just
> don't stand out in the same way because the entire mitigation
> sequence is absent
> on one vendor the other, i.e. they don't look wrong at first glance. 
> But if KVM
> could have a mostly unified VM-Enter => VM-Exit assembly code, I
> would happliy eat
> a dead NOP/JMP or three.  Now that I look at it, that actually seems
> very doable...

Sure.  I think some of the fallacy there is also to treat VMX and SVM
as similar (while not treating the Arm side as similar).  They are
different implementations, with several overlapping details - but it's
perilous to think everything maps the same across vendors.


		Amit