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@citrix.com>
---
xen/arch/x86/hvm/hvm.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 23bd7f078a1d..0c60faa39d7b 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -567,9 +567,15 @@ static int cf_check hvm_print_line(
ASSERT(bytes == 1 && port == XEN_HVM_DEBUGCONS_IOPORT);
- /* Deny any input requests. */
- if ( dir != IOREQ_WRITE )
- return X86EMUL_UNHANDLEABLE;
+ if ( dir == IOREQ_READ )
+ {
+ /*
+ * According to Bochs documentation, reading from the E9 port should
+ * return 0xE9 if the "port E9 hack" is implemented.
+ */
+ *val = XEN_HVM_DEBUGCONS_IOPORT;
+ return X86EMUL_OKAY;
+ }
if ( !is_console_printable(c) )
return X86EMUL_OKAY;
--
2.51.0
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@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> That's been wrong for rather a long time. How did you find it? CC-ing Oleksii as you've tagged this for 4.21. > --- > xen/arch/x86/hvm/hvm.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > index 23bd7f078a1d..0c60faa39d7b 100644 > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -567,9 +567,15 @@ static int cf_check hvm_print_line( > > ASSERT(bytes == 1 && port == XEN_HVM_DEBUGCONS_IOPORT); > > - /* Deny any input requests. */ > - if ( dir != IOREQ_WRITE ) > - return X86EMUL_UNHANDLEABLE; > + if ( dir == IOREQ_READ ) > + { > + /* > + * According to Bochs documentation, reading from the E9 port should > + * return 0xE9 if the "port E9 hack" is implemented. > + */ > + *val = XEN_HVM_DEBUGCONS_IOPORT; > + return X86EMUL_OKAY; > + } > > if ( !is_console_printable(c) ) > return X86EMUL_OKAY;
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@citrix.com> > > Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> > > 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. > CC-ing Oleksii as you've tagged this for 4.21. I was told that bugfixes didn't need a release-ack until hard code freeze, which is the 31st of October? Thanks, Roger.
On 10/2/25 3:38 PM, 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@citrix.com> >> Reviewed-by: Andrew Cooper<andrew.cooper3@citrix.com> >> >> 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. > >> CC-ing Oleksii as you've tagged this for 4.21. > I was told that bugfixes didn't need a release-ack until hard code > freeze, which is the 31st of October? I meant until the start of the hard code freeze, which is on October 4. So there is no need for a release-ack for this patch. Thanks. ~ Oleksii
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@citrix.com> >> >> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> >> >> 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? Cheers, Alejandro
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@citrix.com> > >> > >> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> > >> > >> 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.
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@citrix.com> >> >> >> >> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> >> >> >> >> 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. Cheers, Alejandro
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@citrix.com> > >> >> > >> >> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> > >> >> > >> >> 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? Is there any testing XTF should do to ensure the serial is there, before blindly writing at 0x3f8? Thanks, Roger.
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@citrix.com> >> >> >> >> >> >> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> >> >> >> >> >> >> 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
© 2016 - 2025 Red Hat, Inc.