Re: [PATCH] x86/tdx: Remove the early #VE handler

[Kiryl Shutsemau]

On Fri, Sep 11, 2026 at 03:24:34PM +0000, Edgecombe, Rick P wrote:
> On Fri, 2026-09-11 at 11:37 +0100, Kiryl Shutsemau wrote:
> > > Reviewed-by: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
> > 
> > Rick, could you actually test it?
> 
> I didn't test it myself, but discussed with Vishal his testing.
> 
> > 
> > Are we sure there's no other port I/O in before idt_setup_early_traps()?
> 
> It was a concern that some other feature besides early printk might use port io.
> But none were found. Andi's recollection was that he hit something that needed
> this, but this may have been with some older changed early printk behavior.
> 
> > 
> > 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
> 
> 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.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov