From: Binbin Wu <binbin.wu@linux.intel.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>
Cc: pbonzini@redhat.com, seanjc@google.com, kvm@vger.kernel.org,
rick.p.edgecombe@intel.com, kai.huang@intel.com,
adrian.hunter@intel.com, reinette.chatre@intel.com,
tony.lindgren@linux.intel.com, isaku.yamahata@intel.com,
yan.y.zhao@intel.com, chao.gao@intel.com, michael.roth@amd.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] KVM: TDX: Add a place holder to handle TDX VM exit
Date: Wed, 18 Dec 2024 09:33:48 +0800 [thread overview]
Message-ID: <7b097d2c-6490-4fc8-987c-7383d19b4b3c@linux.intel.com> (raw)
In-Reply-To: <646990e1-cce6-4040-af40-6d80e0cd954a@intel.com>
On 12/16/2024 12:37 PM, Xiaoyao Li wrote:
> On 12/16/2024 8:54 AM, Binbin Wu wrote:
>>
>>
>>
>> On 12/13/2024 4:57 PM, Xiaoyao Li wrote:
>>> On 12/1/2024 11:53 AM, Binbin Wu wrote:
> ...
>>>
>>>> }
>>>> void tdx_load_mmu_pgd(struct kvm_vcpu *vcpu, hpa_t root_hpa, int pgd_level)
>>>> @@ -1135,6 +1215,88 @@ int tdx_sept_remove_private_spte(struct kvm *kvm, gfn_t gfn,
>>>> return tdx_sept_drop_private_spte(kvm, gfn, level, pfn);
>>>> }
>>>> +int tdx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t fastpath)
>>>> +{
>>>> + struct vcpu_tdx *tdx = to_tdx(vcpu);
>>>> + u64 vp_enter_ret = tdx->vp_enter_ret;
>>>> + union vmx_exit_reason exit_reason;
>>>> +
>>>> + if (fastpath != EXIT_FASTPATH_NONE)
>>>> + return 1;
>>>> +
>>>> + /*
>>>> + * Handle TDX SW errors, including TDX_SEAMCALL_UD, TDX_SEAMCALL_GP and
>>>> + * TDX_SEAMCALL_VMFAILINVALID.
>>>> + */
>>>> + if (unlikely((vp_enter_ret & TDX_SW_ERROR) == TDX_SW_ERROR)) {
>>>> + KVM_BUG_ON(!kvm_rebooting, vcpu->kvm);
>>>> + goto unhandled_exit;
>>>> + }
>>>> +
>>>> + /*
>>>> + * Without off-TD debug enabled, failed_vmentry case must have
>>>> + * TDX_NON_RECOVERABLE set.
>>>> + */
>>>
>>> This comment is confusing. I'm not sure why it is put here. Below code does nothing with exit_reason.failed_vmentry.
>>
>> Because when failed_vmentry occurs, vp_enter_ret will have
>> TDX_NON_RECOVERABLE set, so it will be handled below.
>
> The words somehow is confusing, which to me is implying something like:
>
> WARN_ON(!debug_td() && exit_reason.failed_vmentry &&
> !(vp_enter_ret & TDX_NON_RECOVERABLE))
The comment tried to say that the failed_vmentry case is also covered by
TDX_NON_RECOVERABLE since currently off-TD debug is not supported yet.
Since it's causing confusion, I'd like to add the code the handle the
failed_vmentry separately and aligned to VMX by using KVM_EXIT_FAIL_ENTRY
as suggested below.
>
> Besides, VMX returns KVM_EXIT_FAIL_ENTRY for vm-entry failure. So the question is why TDX cannot do it same way?
>
>>>
>>>> + if (unlikely(vp_enter_ret & (TDX_ERROR | TDX_NON_RECOVERABLE))) {
>>>> + /* Triple fault is non-recoverable. */
>>>> + if (unlikely(tdx_check_exit_reason(vcpu, EXIT_REASON_TRIPLE_FAULT)))
>>>> + return tdx_handle_triple_fault(vcpu);
>>>> +
>>>> + kvm_pr_unimpl("TD vp_enter_ret 0x%llx, hkid 0x%x hkid pa 0x%llx\n",
>>>> + vp_enter_ret, to_kvm_tdx(vcpu->kvm)->hkid,
>>>> + set_hkid_to_hpa(0, to_kvm_tdx(vcpu->kvm)->hkid));
>>>
>>> It indeed needs clarification for the need of "hkid" and "hkid pa". Especially the "hkdi pa", which is the result of applying HKID of the current TD to a physical address 0. I cannot think of any reason why we need such info.
>> Yes, set_hkid_to_hpa(0, to_kvm_tdx(vcpu->kvm)->hkid) should be removed.
>> I didn't notice it.
>
> don't forget to justify why HKID is useful here. To me, HKID can be dropped as well.
OK.
>
>> Thanks!
>>
>>
>>>
>>>> + goto unhandled_exit;
>>>> + }
>>>> +
>>>> + /* From now, the seamcall status should be TDX_SUCCESS. */
>>>> + WARN_ON_ONCE((vp_enter_ret & TDX_SEAMCALL_STATUS_MASK) != TDX_SUCCESS);
>>>
>>> Is there any case that TDX_SUCCESS with additional non-zero information in the lower 32-bits? I thought TDX_SUCCESS is a whole 64- bit status code.
>> TDX status code uses the upper 32-bits.
>>
>> When the status code is TDX_SUCCESS and has a valid VMX exit reason, the lower
>> 32-bit is the VMX exit reason.
>>
>> You can refer to the TDX module ABI spec or interface_function_completion_status.json
>> from the intel-tdx-module-1.5-abi-table for details.
>>
>
> I see. (I asked a silly question that I even missed the normal Exit case)
>
>
next prev parent reply other threads:[~2024-12-18 1:33 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-01 3:53 [PATCH 0/7] KVM: TDX: TDX hypercalls may exit to userspace Binbin Wu
2024-12-01 3:53 ` [PATCH 1/7] KVM: TDX: Add a place holder to handle TDX VM exit Binbin Wu
2024-12-09 11:21 ` Chao Gao
2024-12-10 2:14 ` Binbin Wu
2024-12-13 8:57 ` Xiaoyao Li
2024-12-16 0:54 ` Binbin Wu
2024-12-16 4:37 ` Xiaoyao Li
2024-12-18 1:33 ` Binbin Wu [this message]
2025-01-22 12:50 ` Paolo Bonzini
2024-12-01 3:53 ` [PATCH 2/7] KVM: TDX: Add a place holder for handler of TDX hypercalls (TDG.VP.VMCALL) Binbin Wu
2024-12-09 11:28 ` Chao Gao
2024-12-10 2:34 ` Binbin Wu
2024-12-01 3:53 ` [PATCH 3/7] KVM: TDX: Handle KVM hypercall with TDG.VP.VMCALL Binbin Wu
2024-12-09 2:58 ` Chao Gao
2024-12-09 3:08 ` Binbin Wu
2024-12-01 3:53 ` [PATCH 4/7] KVM: TDX: Handle TDG.VP.VMCALL<MapGPA> Binbin Wu
2024-12-09 12:45 ` Chao Gao
2024-12-10 2:51 ` Binbin Wu
2024-12-10 9:10 ` Chao Gao
2024-12-10 9:27 ` Tony Lindgren
2024-12-13 9:32 ` Xiaoyao Li
2024-12-16 1:08 ` Binbin Wu
2024-12-16 6:03 ` Xiaoyao Li
2024-12-18 1:38 ` Binbin Wu
2024-12-18 5:09 ` Binbin Wu
2024-12-01 3:53 ` [PATCH 5/7] KVM: TDX: Handle TDG.VP.VMCALL<ReportFatalError> Binbin Wu
2024-12-06 9:31 ` Xu Yilun
2024-12-06 9:37 ` Binbin Wu
2024-12-10 9:05 ` Chao Gao
2024-12-10 9:43 ` Binbin Wu
2024-12-13 9:40 ` Xiaoyao Li
2024-12-16 1:14 ` Binbin Wu
2024-12-01 3:53 ` [PATCH 6/7] KVM: TDX: Handle TDX PV port I/O hypercall Binbin Wu
2024-12-10 9:42 ` Chao Gao
2024-12-10 9:50 ` Binbin Wu
2024-12-01 3:53 ` [PATCH 7/7] KVM: TDX: Handle TDX PV MMIO hypercall Binbin Wu
2024-12-10 18:24 ` [PATCH 0/7] KVM: TDX: TDX hypercalls may exit to userspace Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7b097d2c-6490-4fc8-987c-7383d19b4b3c@linux.intel.com \
--to=binbin.wu@linux.intel.com \
--cc=adrian.hunter@intel.com \
--cc=chao.gao@intel.com \
--cc=isaku.yamahata@intel.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=reinette.chatre@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=tony.lindgren@linux.intel.com \
--cc=xiaoyao.li@intel.com \
--cc=yan.y.zhao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox