From: Kiryl Shutsemau <kas@kernel.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "Verma, Vishal L" <vishal.l.verma@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"ak@linux.intel.com" <ak@linux.intel.com>
Subject: Re: [PATCH] x86/tdx: Remove the early #VE handler
Date: Fri, 11 Sep 2026 11:37:07 +0100 [thread overview]
Message-ID: <aqPTIyi--7f2Fzxm@thinkstation> (raw)
In-Reply-To: <b41da075607d1eaa9d96eddbf3acc24502edd604.camel@intel.com>
On Thu, Sep 10, 2026 at 08:39:47PM +0000, Edgecombe, Rick P wrote:
> On Thu, 2026-09-10 at 12:28 -0600, Vishal Verma wrote:
> > tdx_early_handle_ve() emulates port I/O for #VEs taken before
> > idt_setup_early_traps() installs the real #VE gate. Per commit
> > 32e72854fa5f ("x86/tdx: Port I/O: Add early boot support"), it exists to
> > support earlyprintk's serial driver.
> >
> > "earlyprintk=" and "earlycon=" are both early_param() handlers, so no
> > console can be registered before parse_early_param(), which runs from
> > setup_arch(), after idt_setup_early_traps() has replaced the early IDT.
> > Nothing in the window between idt_setup_early_handler() and
> > idt_setup_early_traps() does port I/O, so this emulation doesn't ever
> > get called.
> >
> > Remove the handler. Any #VE in the early window now falls through to
> > early_fixup_exception(), as it previously did for #VEs that were not I/O
> > instructions.
> >
> > Found with the help of an LLM observing that the real IDT is installed
> > before parse_early_param(). LLMs were also used to verify this. On a TDX
> > guest booted with earlyprintk, a counter added to tdx_early_handle_ve()
> > for testing remained 0 after boot.
>
> The logic and history makes sense to me. I'm surprised early printk is not
> useful this early.
>
> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Rick, could you actually test it?
Are we sure there's no other port I/O in before idt_setup_early_traps()?
I don't see anything direct, but exception path is different story.
native_machine_emergency_restart() does port I/O for BOOT_KBD which
seems to be reachable and leads to #VE with the patch:
machine_emergency_restart()
__machine_emergency_restart(1)
machine_ops.emergency_restart()
native_machine_emergency_restart()
reboot_type == BOOT_ACPI (default)
acpi_reboot()
reboot_type = BOOT_KBD
kb_wait()
inb(0x64) --> #VE
Could you check if the patch changes panic() behaviour in the window
before idt_setup_early_traps()?
--
Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2026-09-11 10:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 18:28 [PATCH] x86/tdx: Remove the early #VE handler 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 [this message]
2026-09-11 15:24 ` Edgecombe, Rick P
2026-09-11 16:07 ` Kiryl Shutsemau
2026-09-11 17:51 ` Edgecombe, Rick P
2026-09-21 21:20 ` Verma, Vishal L
2026-09-22 10:19 ` Kiryl Shutsemau
2026-09-22 17:45 ` Verma, Vishal L
2026-09-24 10:48 ` Kiryl Shutsemau
2026-09-29 11:15 ` Nikolay Borisov
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=aqPTIyi--7f2Fzxm@thinkstation \
--to=kas@kernel.org \
--cc=ak@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=rick.p.edgecombe@intel.com \
--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 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.