Re: [PATCH v2 1/8] KVM: x86: Have ____kvm_emulate_hypercall() read the GPRs

[Xiaoyao Li <xiaoyao.li@intel.com>]

On 2/12/2025 9:32 AM, Binbin Wu wrote:
> 
> 
> On 2/11/2025 6:23 PM, Xiaoyao Li wrote:
>> On 2/11/2025 10:54 AM, Binbin Wu wrote:
>>> Have ____kvm_emulate_hypercall() read the GPRs instead of passing them
>>> in via the macro.
>>>
>>> When emulating KVM hypercalls via TDVMCALL, TDX will marshall 
>>> registers of
>>> TDVMCALL ABI into KVM's x86 registers to match the definition of KVM
>>> hypercall ABI _before_ ____kvm_emulate_hypercall() gets called. 
>>> Therefore,
>>> ____kvm_emulate_hypercall() can just read registers internally based 
>>> on KVM
>>> hypercall ABI, and those registers can be removed from the
>>> __kvm_emulate_hypercall() macro.
>>>
>>> Also, op_64_bit can be determined inside ____kvm_emulate_hypercall(),
>>> remove it from the __kvm_emulate_hypercall() macro as well.
>>
>> After this patch, __kvm_emulate_hypercall() becomes superfluous.
>> we can just put the logic to call the "complete_hypercall" into 
>> ____kvm_emulate_hypercall() and rename it to __kvm_emulate_hypercall()
>>
>>
> According to the commit message of
> "KVM: x86: Refactor __kvm_emulate_hypercall() into a macro":
> "Rework __kvm_emulate_hypercall() into a macro so that completion of
> hypercalls that don't exit to userspace use direct function calls to the
> completion helper, i.e. don't trigger a retpoline when RETPOLINE=y."

I see.

I thought the purpose of introducing the macro was for TDX usage. My 
fault that didn't checking the commit message of that change.

It makes sense for retpoline reason.

> So I kept the macro.