On Wed, Aug 28, 2024, Rick P Edgecombe wrote: > On Tue, 2024-06-04 at 12:34 -0700, Sean Christopherson wrote: > > > > If we're willing to suffer a few gnarly macros, I think we get a > > satisfactory mix of standardized arguments and explicit operands, and > > generate vastly better code. > > Hi Sean, > > We are kind of stuck on improving the code generation for the existing calls. > x86 maintainers don't seem to be enthusiastic about tackling this urgently and > there is not consensus on how to weigh source code clarity with code generation > sanity [0]. I think we are going to table it for the time being, unless it's a > showstopper for you. I'll survive. > An option is still to have a separate helper infrastructure for KVM's calls, but > as discussed originally this duplicates code. Ya. Tangentially related to this topic, at some point in the not-to-distant future, I think we need to have a discussion for how to maintain TDX (and SNP) going forward. Not because I want to take more ownership in KVM (I would generally prefer to do the opposite), but because I suspect there will be more overlaps similar to this in the future, e.g. if the guest kernel gets cornered into doing some amount of SSE/AVX emulation for userspace MMIO. And because I also suspect that future additions to TDX and SNP will require modifications and tighter integration in/with subsystems outside of KVM, while simultaneously moving further away from the areas that KVM has historically operated in, e.g. emulation, feature enumeration, memory management, etc. I don't have any concrete (or even half-baked) thoughts, just flagging that we might want to have a conversation to hash out what we think would be the best way to operate, knowing what's on the horizon, versus winging it as we go and hoping everything works out.
