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 <[email protected]>
>> ---
>> 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
