On Mon, Jan 20, 2025, Binbin Wu wrote: > On 1/18/2025 3:31 AM, Sean Christopherson wrote: > > On Wed, Jan 15, 2025, Binbin Wu wrote: > > > On 12/19/2024 10:40 AM, Sean Christopherson wrote: > > > > On Wed, 27 Nov 2024 16:43:38 -0800, Sean Christopherson wrote: > > > > > Effectively v4 of Binbin's series to handle hypercall exits to userspace in > > > > > a generic manner, so that TDX > > > > > > > > > > Binbin and Kai, this is fairly different that what we last discussed. While > > > > > sorting through Binbin's latest patch, I stumbled on what I think/hope is an > > > > > approach that will make life easier for TDX. Rather than have common code > > > > > set the return value, _and_ have TDX implement a callback to do the same for > > > > > user return MSRs, just use the callback for all paths. > > > > > > > > > > [...] > > > > Applied patch 1 to kvm-x86 fixes. I'm going to hold off on the rest until the > > > > dust settles on the SEAMCALL interfaces, e.g. in case TDX ends up marshalling > > > > state into the "normal" GPRs. > > > Hi Sean, Based on your suggestions in the link > > > https://lore.kernel.org/kvm/Z1suNzg2Or743a7e@xxxxxxxxxx, the v2 of "KVM: TDX: > > > TDX hypercalls may exit to userspace" is planned to morph the TDG.VP.VMCALL > > > with KVM hypercall to EXIT_REASON_VMCALL and marshall r10~r14 from > > > vp_enter_args in struct vcpu_tdx to the appropriate x86 registers for KVM > > > hypercall handling. > > ... > > > > > To test TDX, I made some modifications to your patch > > > "KVM: x86: Refactor __kvm_emulate_hypercall() into a macro" > > > Are the following changes make sense to you? > > Yes, but I think we can go a step further and effectively revert the bulk of commit > > e913ef159fad ("KVM: x86: Split core of hypercall emulation to helper function"), > > i.e. have ____kvm_emulate_hypercall() read the GPRs instead of passing them in > > via the macro. > > Sure. > > Are you OK if I sent the change (as a prep patch) along with v2 of > "TDX hypercalls may exit to userspace"? Ya, go for it.
