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

[Alejandro Vallejo <alejandro.garciavallejo@amd.com>]

On Thu Oct 2, 2025 at 5:37 PM CEST, Roger Pau Monné wrote:
> 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@amd.com>
>> >> ---
>> >>  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.

Maybe NATIVE, XEN_VIRT and NON_XEN_VIRT? I see no reason to distinguish between
TCG, KVM and any other accelerator; and QEMU is imprecise because we use for
HVM. You could imagine chainloading XTF from GRUB to test the HVM env.

>
>> 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.

Seems pretty obvious it was intentional. As to what the intention was, your
guess is as good as mine.

Cheers,
Alejandro