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.
