Re: [PATCH for-4.21] x86/hvm: fix reading from 0xe9 IO port if port E9 hack is active

[Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>]

On Fri Oct 3, 2025 at 10:18 AM CEST, Roger Pau Monné wrote:
> On Thu, Oct 02, 2025 at 04:56:48PM +0200, Alejandro Vallejo wrote:
>> On Thu Oct 2, 2025 at 4:17 PM CEST, Roger Pau Monné wrote:
>> > On Thu, Oct 02, 2025 at 04:02:00PM +0200, Alejandro Vallejo wrote:
>> >> On Thu Oct 2, 2025 at 3:38 PM CEST, Roger Pau Monné wrote:
>> >> > On Thu, Oct 02, 2025 at 11:37:36AM +0100, Andrew Cooper wrote:
>> >> >> On 02/10/2025 11:22 am, Roger Pau Monne wrote:
>> >> >> > Reading from the E9 port if the emergency console is active should 
>> >> >> > return
>> >> >> > 0xe9 according to the documentation from Bochs:
>> >> >> >
>> >> >> > https://bochs.sourceforge.io/doc/docbook/user/bochsrc.html
>> >> >> >
>> >> >> > See `port_e9_hack` section description.
>> >> >> >
>> >> >> > Fix Xen so it also returns the port address.  OSes can use it to 
>> >> >> > detect
>> >> >> > whether the emergency console is available or not.
>> >> >> >
>> >> >> > Fixes: d1bd157fbc9b ("Big merge the HVM full-virtualisation 
>> >> >> > abstractions.")
>> >> >> > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>> >> >> 
>> >> >> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> >> >> 
>> >> >> That's been wrong for rather a long time.  How did you find it?
>> >> >
>> >> > I came across the documentation above and I didn't remember Xen
>> >> > returning any value for reads, which sadly was indeed true.
>> >> >
>> >> > This was because I had the intention to suggest Alejandro to (also?) use
>> >> > the port 0xe9 hack for printing from XTF, which should work for both
>> >> > Xen and QEMU.
>> >> 
>> >> QEMU doesn't support 0xE9 though?
>> >
>> > AFAICT it does:
>> >
>> > https://wiki.osdev.org/QEMU#The_debug_console
>> >
>> > However when running QEMU on Xen as a device model writes to 0xe9 are
>> > handled in the hypervisor, and never forwarded to any device model.
>> >
>> > Regards, Roger.
>> 
>> The more you know. I searched for it once upon a time and couldn't find it.
>> Thanks for the pointer.
>> 
>> Regardless, "-debugcon stdio" is functionally equivalent to "-serial stdio"
>> and the latter can be adapted to work on real hardware too.
>
> The emulated serial is possibly equivalent to the 0xe9 hack in QEMU,
> as I expect the serial is mostly setup to "just work".  On native you
> likely need to configure the baud rate &c, plus implement flow
> control?

You'd need to boot XTF via GRUB (or similar), which would've pre-configured
the serial port for you.

And baud rate, flow control and the like are ignored when emulated, so that's
all fine.

>
> Is there any testing XTF should do to ensure the serial is there,
> before blindly writing at 0x3f8?

Closest would be parsing the FADT for LEGACY_DEVICES being set, but if that was
clear we'd be out of options because there's nothing else to write to. I don't
intend to make XTF rock solid on real hardware, just "workable" on typical
everyday devices/servers with GRUB's help.

FWIW Xen just assumes it's there if com1= is given in the cmdline AFAICS. The
most likely case for COM1 not being there is on PV(H), which XTF already uses
the PV console for.

Cheers,
Alejandro