Re: [XTF PATCH v2 2/2] x86: Allow exiting QEMU in TCG/QEMU

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Oct 02, 2025 at 04:48:38PM +0200, Alejandro Vallejo wrote:
> On Thu Oct 2, 2025 at 4:22 PM CEST, Roger Pau Monné wrote:
> > On Thu, Oct 02, 2025 at 03:55:34PM +0200, Alejandro Vallejo wrote:
> >> If QEMU has a debug isa-debug-exit device, we can simply write to it
> >> to exit rather than spinning after a failed hypercall.
> >> 
> >> While at it, reorder an out-of-order include.
> >> 
> >> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>
> >> ---
> >>  arch/x86/hvm/traps.c    | 16 +++++++++++++++-
> >>  arch/x86/pv/traps.c     |  5 +++++
> >>  common/lib.c            |  2 +-
> >>  common/report.c         |  8 +++++---
> >>  include/xtf/framework.h |  3 +++
> >>  5 files changed, 29 insertions(+), 5 deletions(-)
> >> 
> >> diff --git a/arch/x86/hvm/traps.c b/arch/x86/hvm/traps.c
> >> index ad7b8cb..b8c4d0c 100644
> >> --- a/arch/x86/hvm/traps.c
> >> +++ b/arch/x86/hvm/traps.c
> >> @@ -1,5 +1,6 @@
> >> -#include <xtf/traps.h>
> >> +#include <xtf/hypercall.h>
> >>  #include <xtf/lib.h>
> >> +#include <xtf/traps.h>
> >>  
> >>  #include <arch/idt.h>
> >>  #include <arch/lib.h>
> >> @@ -139,6 +140,19 @@ void arch_init_traps(void)
> >>                 virt_to_gfn(__end_user_bss));
> >>  }
> >>  
> >> +void arch_shutdown(unsigned int reason)
> >> +{
> >> +    hypercall_shutdown(reason);
> >
> > This relies on the hypercall page being poised with `ret`, which is
> > IMO fragile.  I would rather have it poisoned with `int3` and prevent
> > such stray accesses in the first place.
> 
> I dont' mind caching Xen presence somewhere, but that involves some code 
> motion
> from setup.c, which I wanted to avoid.

I think it's very likely that at some point we will need to cache this?

enum {
    NATIVE,
    XEN,
    QEMU,
    ...
} hypervisor_env;

Or similar.

> At the core I just want to speed up testmaking by doing it from WSL rather 
> than
> from a Xen host.

Right.  I was pondering whether we want a QEMU target, but
realistically QEMU should be able to run all the hvm* variants.

> >
> >> +
> >> +    /*
> >> +     * Not running under Xen. Attempt exit via the QEMU ISA debug exit 
> >> device on
> >> +     * its default port.
> >> +     *
> >> +     * QEMU's rc is (reason << 1) | 1, if "-device isa-debug-exit" is set.
> >> +     */
> >> +    outb(reason, 0x501);
> >
> > That's kind of weird?  So even if we pass reason == 0, the exit code
> > from QEMU will be 1 (and error)?
> >
> > Isn't there anyway to signal a clean shutdown, and hence QEMU exit
> > code being 0?
> 
> Nope. It's hardcoded in QEMU itself.
> 
> reason=0 => rc=1
> reason=1 => rc=3
> reason=2 => rc=5
> 
> ... and so on.

Hm, OK, I think it's lacking there's no way to signal a clean exit,
but I guess QEMU had a reason for this.

> I have something like this in my harness to avoid surprises:
> 
>   set +e
>   qemu-system-x86_64 <...>
>   RC="$?"
>   printf "\n[QEMU exit] rc=${RC} reason=$(($RC / 2))\n"
> 
> On other test harness I use for personal projects I take the convention that
> rc = 1 means success and anything else means failure, but that needs changes
> to the runner to integrate the assumptions somewhere, I don't think hardcoding
> my conventions is sensible.

I see, I find it kind of lacking from QEMU, but never mind, not
something we can change.

Thanks, Roger.