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