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

[Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>]

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.

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

>
>> +
>> +    /*
>> +     * 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.

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.

Cheers,
Alejandro