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

[Sean Christopherson]

On Mon, Jul 22, 2024, Amit Shah wrote:
> On Tue, 2024-07-16 at 12:10 -0700, Sean Christopherson wrote:
> > 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).

Bringing ARM into the picture is little more than whataboutism.  KVM x86 and KVM
arm64 _can't_ share assembly.  They _can't_ share things like MSR interception
tracking because MSRs are 100% an x86-only concept.  The fact that sharing code
across x86 and ARM is challenging doesn't have any bearing on whether or not
VMX and SVM can/should share code.

> They are different implementations, with several overlapping details - but
> it's perilous to think everything maps the same across vendors.

I never said everything maps the same.  The point I am trying to make is that
there is significant value _for KVM_ in having common code between architectures,
and between vendors within an architecture.  I can provide numerous examples
where something was implemented/fixed in vendor/arch code, and then later it was
discovered that the feature/fix was also wanted/needed in other vendor/arch code.