From: "Huang, Kai" <kai.huang@intel.com>
To: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "Li, Xiaoyao" <xiaoyao.li@intel.com>, lkp <lkp@intel.com>
Subject: Re: [PATCH] x86/tdx: mark tdh_vp_enter() as __flatten
Date: Tue, 27 May 2025 11:07:38 +0000 [thread overview]
Message-ID: <3d257fce5c37e6bd73648614bfaabc26de95737f.camel@intel.com> (raw)
In-Reply-To: <dba9b129a3d6407948f165b885f9c72975e3231b.camel@intel.com>
On Mon, 2025-05-26 at 23:10 +0000, Huang, Kai wrote:
> On Mon, 2025-05-26 at 16:45 -0400, Paolo Bonzini wrote:
> > In some cases tdx_tdvpr_pa() is not fully inlined into tdh_vp_enter(), which
> > causes the following warning:
> >
> > vmlinux.o: warning: objtool: tdh_vp_enter+0x8: call to tdx_tdvpr_pa() leaves .noinstr.text section
> >
> > This happens if the compiler considers tdx_tdvpr_pa() to be "large", for example
> > because CONFIG_SPARSEMEM adds two function calls to page_to_section() and
> > __section_mem_map_addr():
> >
> > ({ const struct page *__pg = (pg); \
> > int __sec = page_to_section(__pg); \
> > (unsigned long)(__pg - __section_mem_map_addr(__nr_to_section(__sec)));
> > \
> > })
>
> Just FYI the above warning can also be triggered when CONFIG_SPARSEMEM_VMEMMAP=y
> (and CONFIG_SPARSEMEM=y as well), in which case the __page_to_pfn() is simply:
>
> #define __page_to_pfn(page) (unsigned long)((page) - vmemmap)
>
> The function call to page_to_section() and __section_mem_map_addr() only happens
> when CONFIG_SPARSEMEM_VMEMMAP=n while CONFIG_SPARSEMEM=y.
>
[...]
>
> I did some test and can confirm this patch can silence the warning mentioned in
> the changelog.
>
> However, with this patch applied, I also tested the case that
> CONFIG_SPARSEMEM_VMEMMAP=n and CONFIG_SPARSEMEM=y [1], but I still got:
>
> vmlinux.o: warning: objtool: tdh_vp_enter+0x10: call to page_to_section() leaves
> .noinstr.text section
>
> Not sure why, but it seems __flatten failed to work as expected, as least
> recursively.
>
I found a recently merged patch from Kirill has made CONFIG_SPARSEMEM_VMEMAP
always true on x86_64:
https://lore.kernel.org/lkml/174748683804.406.11521945321481191771.tip-bot2@tip-bot2/
So we don't need to worry about the case that CONFIG_SPARSEMEM_VMEMMAP=n and
CONFIG_SPARSEMEM=y.
The changelog could be simplified/updated though I think (since seems there's no
need to mention the "large" case now).
So:
Tested-by: Kai Huang <kai.huang@intel.com>
Acked-by: Kai Huang <kai.huang@intel.com>
next prev parent reply other threads:[~2025-05-27 11:07 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 [this message]
2025-05-27 13:54 ` Sean Christopherson
2025-05-27 16:19 ` Edgecombe, Rick P
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=3d257fce5c37e6bd73648614bfaabc26de95737f.camel@intel.com \
--to=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=pbonzini@redhat.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.