From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "kas@kernel.org" <kas@kernel.org>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"Verma, Vishal L" <vishal.l.verma@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"ak@linux.intel.com" <ak@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>
Subject: Re: [PATCH] x86/tdx: Remove the early #VE handler
Date: Fri, 11 Sep 2026 17:51:29 +0000 [thread overview]
Message-ID: <0c7c383697e781ddb4cc86213d75819532ee05b0.camel@intel.com> (raw)
In-Reply-To: <aqQmNeXQv05SK86g@thinkstation>
On Fri, 2026-09-11 at 17:07 +0100, Kiryl Shutsemau wrote:
> > Is BOOT_KBD something that you think could be hit from a TDX guest?
>
> It is the first fallback from default BOOT_ACPI failure. But it is just
> an example of port I/O I found.
>
> > > Could you check if the patch changes panic() behaviour in the window
> > > before idt_setup_early_traps()?
> >
> > Can you describe more what you are imagining? panic() doing early printk or
> > some other port io? Wondering if you have some more specific hunch.
>
> I don't see panic() triggering early printk, but I see potential path to
> other port I/O as pointed above.
>
> I have vague recollection that I tried to remove it before, but
> something stopped me.
Yea, the risk is that some other usage is relying on this, even though the
comment in the handler says "Intended only for earlyprintk".
When doing the initial TDX guest work, did you guys consider trying to use some
alternatives magic to redirect #VE causing things to the tdvmcall helpers? I
guess it doesn't help the early boot case.
prev parent reply other threads:[~2026-09-11 17:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 18:28 Vishal Verma
2026-09-10 20:39 ` Edgecombe, Rick P
2026-09-11 0:15 ` Verma, Vishal L
2026-09-11 10:37 ` Kiryl Shutsemau
2026-09-11 15:24 ` Edgecombe, Rick P
2026-09-11 16:07 ` Kiryl Shutsemau
2026-09-11 17:51 ` Edgecombe, Rick P [this message]
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=0c7c383697e781ddb4cc86213d75819532ee05b0.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=ak@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=kas@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=vishal.l.verma@intel.com \
--cc=x86@kernel.org \
/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
all inboxes | Powered by JetHome®