From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "seanjc@google.com" <seanjc@google.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"Annapurve, Vishal" <vannapurve@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Zhao, Yan Y" <yan.y.zhao@intel.com>,
"michael.roth@amd.com" <michael.roth@amd.com>,
"Weiny, Ira" <ira.weiny@intel.com>
Subject: Re: [RFC PATCH 06/12] KVM: TDX: Return -EIO, not -EINVAL, on a KVM_BUG_ON() condition
Date: Thu, 28 Aug 2025 20:13:25 +0000 [thread overview]
Message-ID: <9e55a0e767317d20fc45575c4ed6dafa863e1ca0.camel@intel.com> (raw)
In-Reply-To: <aLCsM6DShlGDxPOd@google.com>
On Thu, 2025-08-28 at 12:21 -0700, Sean Christopherson wrote:
> Generally speaking, the number of KVM_BUG_ON()s is fine. What we can do though
> is reduce the amount of boilerplate and the number of paths the propagate a SEAMCALL
> err through multiple layers, e.g. by eliminating single-use helpers (which is made
> easier by reducing boilerplate and thus lines of code).
>
> Concretely, if we combine the KVM_BUG_ON() usage with pr_tdx_error():
>
> #define __TDX_BUG_ON(__err, __fn_str, __kvm, __fmt, __args...) \
> ({ \
> struct kvm *_kvm = (__kvm); \
> bool __ret = !!(__err); \
> \
> if (WARN_ON_ONCE(__ret && (!_kvm || !_kvm->vm_bugged))) { \
> if (_kvm) \
> kvm_vm_bugged(_kvm); \
> pr_err_ratelimited("SEAMCALL " __fn_str " failed: 0x%llx" \
> __fmt "\n", __err, __args); \
> } \
> unlikely(__ret); \
> })
>
> #define TDX_BUG_ON(__err, __fn, __kvm) \
> __TDX_BUG_ON(__err, #__fn, __kvm, "%s", "")
>
> #define TDX_BUG_ON_1(__err, __fn, __rcx, __kvm) \
> __TDX_BUG_ON(__err, #__fn, __kvm, ", rcx 0x%llx", __rcx)
>
> #define TDX_BUG_ON_2(__err, __fn, __rcx, __rdx, __kvm) \
> __TDX_BUG_ON(__err, #__fn, __kvm, ", rcx 0x%llx, rdx 0x%llx", __rcx, __rdx)
>
> #define TDX_BUG_ON_3(__err, __fn, __rcx, __rdx, __r8, __kvm) \
> __TDX_BUG_ON(__err, #__fn, __kvm, ", rcx 0x%llx, rdx 0x%llx, r8 0x%llx", __rcx, __rdx, __r8)
In general sounds good. But there it's a bit strange to specify them rcx, rdx,
etc in a general helper. This is fallout from the existing chain of strange
naming:
For example tdh_mem_range_block() plucks them from those registers and calls
them ext_err1 due to their conditional meaning. Then KVM gives them some more
meaning with 'entry' and 'level_state". Then prints them out as original
register names. How about keeping the KVM names, like:
#define TDX_BUG_ON_2(__err, __fn, arg1, arg2, __kvm) \
__TDX_BUG_ON(__err, #__fn, __kvm, ", " #arg1 " 0x%llx, " #arg2 "
0x%llx", arg1, arg2)
so you get: entry: 0x00 level:0xF00
I *think* there is a way to make this work like var args and have a single
function, but it becomes impossible for people to read.
>
>
> And a macro to handle retry when kicking vCPUs out of the guest:
>
> #define tdh_do_no_vcpus(tdh_func, kvm, args...) \
> ({ \
> struct kvm_tdx *__kvm_tdx = to_kvm_tdx(kvm); \
> u64 __err; \
> \
> lockdep_assert_held_write(&kvm->mmu_lock); \
There is a functional change in that the lock assert is not required if BUSY
avoidance can be guaranteed to not happen. I don't think it should be needed
today. I guess it's probably better to not rely on hitting rare races to catch
an issue like that.
> \
> __err = tdh_func(args); \
> if (unlikely(tdx_operand_busy(__err))) { \
> WRITE_ONCE(__kvm_tdx->wait_for_sept_zap, true); \
> kvm_make_all_cpus_request(kvm, KVM_REQ_OUTSIDE_GUEST_MODE); \
> \
> __err = tdh_func(args); \
> \
> WRITE_ONCE(__kvm_tdx->wait_for_sept_zap, false); \
> } \
> __err; \
> })
>
> And do a bit of massaging, then we can end up e.g. this, which IMO is much easier
> to follow than the current form of tdx_sept_remove_private_spte(), which has
> several duplicate sanity checks and error handlers.
>
> The tdh_do_no_vcpus() macro is a little mean, but I think it's a net positive
> as eliminates quite a lot of "noise", and thus makes it easier to focus on the
> logic. And alternative to a trampoline macro would be to implement a guard()
> and then do a scoped_guard(), but I think that'd be just as hard to read, and
> would require almost as much boilerplate as there is today.
>
> static void tdx_sept_remove_private_spte(struct kvm *kvm, gfn_t gfn,
> enum pg_level level, u64 spte)
> {
> struct page *page = pfn_to_page(spte_to_pfn(spte));
> int tdx_level = pg_level_to_tdx_sept_level(level);
> struct kvm_tdx *kvm_tdx = to_kvm_tdx(kvm);
> gpa_t gpa = gfn_to_gpa(gfn);
> u64 err, entry, level_state;
>
> /*
> * HKID is released after all private pages have been removed, and set
> * before any might be populated. Warn if zapping is attempted when
> * there can't be anything populated in the private EPT.
> */
> if (KVM_BUG_ON(!is_hkid_assigned(to_kvm_tdx(kvm)), kvm))
> return;
>
> /* TODO: handle large pages. */
> if (KVM_BUG_ON(level != PG_LEVEL_4K, kvm))
> return;
>
> err = tdh_do_no_vcpus(tdh_mem_range_block, kvm, &kvm_tdx->td, gpa,
> tdx_level, &entry, &level_state);
> if (TDX_BUG_ON_2(err, TDH_MEM_RANGE_BLOCK, entry, level_state, kvm))
> return;
>
> /*
> * TDX requires TLB tracking before dropping private page. Do
> * it here, although it is also done later.
> */
> tdx_track(kvm);
>
> /*
> * When zapping private page, write lock is held. So no race condition
> * with other vcpu sept operation.
> * Race with TDH.VP.ENTER due to (0-step mitigation) and Guest TDCALLs.
> */
> err = tdh_do_no_vcpus(tdh_mem_page_remove, kvm, &kvm_tdx->td, gpa,
> tdx_level, &entry, &level_state);
> if (TDX_BUG_ON_2(err, TDH_MEM_PAGE_REMOVE, entry, level_state, kvm))
> return;
>
> err = tdh_phymem_page_wbinvd_hkid((u16)kvm_tdx->hkid, page);
> if (TDX_BUG_ON(err, TDH_PHYMEM_PAGE_WBINVD, kvm))
> return;
>
> tdx_clear_page(page);
> }
Seems like tasteful macro-ization to me.
next prev parent reply other threads:[~2025-08-28 20:13 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-27 0:05 [RFC PATCH 00/12] KVM: x86/mmu: TDX post-populate cleanups Sean Christopherson
2025-08-27 0:05 ` [RFC PATCH 01/12] KVM: TDX: Drop PROVE_MMU=y sanity check on to-be-populated mappings Sean Christopherson
2025-08-27 8:14 ` Yan Zhao
2025-08-28 0:37 ` Ira Weiny
2025-08-28 2:13 ` Huang, Kai
2025-08-27 0:05 ` [RFC PATCH 02/12] KVM: x86/mmu: Add dedicated API to map guest_memfd pfn into TDP MMU Sean Christopherson
2025-08-27 8:25 ` Yan Zhao
2025-08-28 0:54 ` Edgecombe, Rick P
2025-08-28 1:26 ` Edgecombe, Rick P
2025-08-28 6:23 ` Yan Zhao
2025-08-28 19:40 ` Sean Christopherson
2025-08-29 1:16 ` Yan Zhao
2025-09-01 0:39 ` Yan Zhao
2025-08-28 6:55 ` Yan Zhao
2025-08-28 0:40 ` Ira Weiny
2025-08-28 1:51 ` Edgecombe, Rick P
2025-08-28 19:57 ` Sean Christopherson
2025-08-27 0:05 ` [RFC PATCH 03/12] Revert "KVM: x86/tdp_mmu: Add a helper function to walk down the TDP MMU" Sean Christopherson
2025-08-27 0:05 ` [RFC PATCH 04/12] KVM: x86/mmu: Rename kvm_tdp_map_page() to kvm_tdp_prefault_page() Sean Christopherson
2025-08-28 2:01 ` Edgecombe, Rick P
2025-08-28 18:50 ` Sean Christopherson
2025-08-28 19:04 ` Edgecombe, Rick P
2025-08-27 0:05 ` [RFC PATCH 05/12] KVM: TDX: Drop superfluous page pinning in S-EPT management Sean Christopherson
2025-08-27 8:33 ` Yan Zhao
2025-08-28 2:05 ` Edgecombe, Rick P
2025-08-28 20:16 ` Sean Christopherson
2025-08-28 0:36 ` Ira Weiny
2025-08-28 7:08 ` Yan Zhao
2025-08-28 15:54 ` Ira Weiny
2025-08-28 2:45 ` Huang, Kai
2025-08-27 0:05 ` [RFC PATCH 06/12] KVM: TDX: Return -EIO, not -EINVAL, on a KVM_BUG_ON() condition Sean Christopherson
2025-08-27 8:39 ` Yan Zhao
2025-08-27 17:26 ` Sean Christopherson
2025-08-28 2:11 ` Edgecombe, Rick P
2025-08-28 19:21 ` Sean Christopherson
2025-08-28 20:13 ` Edgecombe, Rick P [this message]
2025-08-28 21:00 ` Sean Christopherson
2025-08-28 21:19 ` Edgecombe, Rick P
2025-08-28 21:34 ` Sean Christopherson
2025-08-28 15:03 ` Ira Weiny
2025-08-27 0:05 ` [RFC PATCH 07/12] KVM: TDX: Avoid a double-KVM_BUG_ON() in tdx_sept_zap_private_spte() Sean Christopherson
2025-08-28 2:19 ` Edgecombe, Rick P
2025-08-28 14:50 ` Edgecombe, Rick P
2025-08-29 1:10 ` Yan Zhao
2025-08-28 15:02 ` Ira Weiny
2025-08-27 0:05 ` [RFC PATCH 08/12] KVM: TDX: Use atomic64_dec_return() instead of a poor equivalent Sean Christopherson
2025-08-28 2:56 ` Edgecombe, Rick P
2025-08-28 6:48 ` Yan Zhao
2025-08-28 19:14 ` Edgecombe, Rick P
2025-08-28 22:33 ` Sean Christopherson
2025-08-28 23:18 ` Edgecombe, Rick P
2025-08-28 15:03 ` Ira Weiny
2025-08-27 0:05 ` [RFC PATCH 09/12] KVM: TDX: Fold tdx_mem_page_record_premap_cnt() into its sole caller Sean Christopherson
2025-08-27 9:02 ` Yan Zhao
2025-08-27 19:08 ` Sean Christopherson
2025-08-28 3:13 ` Edgecombe, Rick P
2025-08-28 5:56 ` Yan Zhao
2025-08-28 19:08 ` Edgecombe, Rick P
2025-08-28 5:43 ` Yan Zhao
2025-08-28 17:00 ` Sean Christopherson
2025-08-28 18:52 ` Edgecombe, Rick P
2025-08-28 20:26 ` Sean Christopherson
2025-08-28 21:33 ` Edgecombe, Rick P
2025-08-28 21:57 ` Sean Christopherson
2025-08-28 23:17 ` Edgecombe, Rick P
2025-08-29 6:08 ` Yan Zhao
2025-08-28 22:06 ` Ira Weiny
2025-08-28 23:17 ` Sean Christopherson
2025-08-29 0:35 ` Ira Weiny
2025-08-29 6:06 ` Yan Zhao
2025-08-28 21:44 ` Sean Christopherson
2025-08-29 2:42 ` Binbin Wu
2025-08-29 2:31 ` Yan Zhao
2025-08-29 6:33 ` Yan Zhao
2025-08-28 15:30 ` Ira Weiny
2025-08-28 15:28 ` Ira Weiny
2025-08-27 0:05 ` [RFC PATCH 10/12] KVM: TDX: Assert that slots_lock is held when nr_premapped is accessed Sean Christopherson
2025-08-27 0:05 ` [RFC PATCH 11/12] KVM: TDX: Track nr_premapped as an "unsigned long", not an "atomic64_t" Sean Christopherson
2025-08-27 9:12 ` Yan Zhao
2025-08-27 0:05 ` [RFC PATCH 12/12] KVM: TDX: Rename nr_premapped to nr_pending_tdh_mem_page_adds Sean Christopherson
2025-08-27 9:22 ` Yan Zhao
2025-08-28 15:23 ` Ira Weiny
2025-08-27 9:48 ` [RFC PATCH 00/12] KVM: x86/mmu: TDX post-populate cleanups Yan Zhao
2025-08-28 19:01 ` Edgecombe, Rick P
2025-08-28 23:19 ` Sean Christopherson
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=9e55a0e767317d20fc45575c4ed6dafa863e1ca0.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=ira.weiny@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=vannapurve@google.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;
as well as URLs for NNTP newsgroup(s).