From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "pbonzini@redhat.com" <pbonzini@redhat.com>,
"seanjc@google.com" <seanjc@google.com>
Cc: "Li, Xiaoyao" <xiaoyao.li@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
lkp <lkp@intel.com>, "Huang, Kai" <kai.huang@intel.com>
Subject: Re: [PATCH] x86/tdx: mark tdh_vp_enter() as __flatten
Date: Tue, 27 May 2025 16:19:36 +0000 [thread overview]
Message-ID: <dc0fd831ac82f313ce9bf8bc3180b7beef565821.camel@intel.com> (raw)
In-Reply-To: <aDXEG5tXRfsSO0Hf@google.com>
On Tue, 2025-05-27 at 13:54 +0000, Sean Christopherson wrote:
> The "standard" kernel way of handling this it to mark the offending helper
> __always_inline, i.e. tag tdx_tdvpr_pa() __always_inline.
>
It looks like __flatten was added after a very similar situation:
https://lore.kernel.org/lkml/CAK8P3a2ZWfNeXKSm8K_SUhhwkor17jFo3xApLXjzfPqX0eUDUA@mail.gmail.com/#t
Since flatten gives the inline decision to the caller instead of the callee,
clang could have the option to keep a non-inline version of tdx_tdvpr_pa() for
whatever reasoning it has. The non-standard behavior around recursive inlining
is unfortunate, but we don't need it here.
The downside is that we would not learn if some code changed in page_to_phys()
and we ended up pulling in some big piece of code for the recursive behavior.
Overall I like the flatten version, but this works too:
diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
index 5699dfe500d9..371b4423a639 100644
--- a/arch/x86/virt/vmx/tdx/tdx.c
+++ b/arch/x86/virt/vmx/tdx/tdx.c
@@ -1501,7 +1501,7 @@ static inline u64 tdx_tdr_pa(struct tdx_td *td)
return page_to_phys(td->tdr_page);
}
-static inline u64 tdx_tdvpr_pa(struct tdx_vp *td)
+static __always_inline u64 tdx_tdvpr_pa(struct tdx_vp *td)
{
return page_to_phys(td->tdvpr_page);
}
> Ditto for tdx_tdr_pa().
> Especially since they're already "inline".
I don't see why tdx_tdr_pa() is required to be inlined. Why force the compiler?
next prev parent reply other threads:[~2025-05-27 16:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-26 20:45 [PATCH] x86/tdx: mark tdh_vp_enter() as __flatten Paolo Bonzini
2025-05-26 23:10 ` Huang, Kai
2025-05-27 11:07 ` Huang, Kai
2025-05-27 13:54 ` Sean Christopherson
2025-05-27 16:19 ` Edgecombe, Rick P [this message]
2025-05-27 19:49 ` 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=dc0fd831ac82f313ce9bf8bc3180b7beef565821.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=xiaoyao.li@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.