[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <de966c9c-54e4-4da2-8dd3-d23b59b279a3@intel.com>
Date: Tue, 11 Feb 2025 18:23:04 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Binbin Wu <binbin.wu@...ux.intel.com>, pbonzini@...hat.com,
seanjc@...gle.com, kvm@...r.kernel.org
Cc: rick.p.edgecombe@...el.com, kai.huang@...el.com, adrian.hunter@...el.com,
reinette.chatre@...el.com, tony.lindgren@...el.com,
isaku.yamahata@...el.com, yan.y.zhao@...el.com, chao.gao@...el.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/8] KVM: x86: Have ____kvm_emulate_hypercall() read
the GPRs
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()
Powered by blists - more mailing lists