[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 2/3] hw/misc: Add mmio-debug-exit device
From: |
Ilya Leoshkevich |
Subject: |
Re: [PATCH 2/3] hw/misc: Add mmio-debug-exit device |
Date: |
Tue, 12 Jul 2022 12:30:04 +0200 |
User-agent: |
Evolution 3.42.4 (3.42.4-2.fc35) |
On Tue, 2022-07-12 at 12:08 +0200, David Hildenbrand wrote:
> On 12.07.22 11:52, Ilya Leoshkevich wrote:
> > On Tue, 2022-07-12 at 10:42 +0530, Richard Henderson wrote:
> > > On 7/12/22 00:26, Ilya Leoshkevich wrote:
> > > > System tests on x86 use isa-debug-exit device in order to
> > > > signal
> > > > success or failure to the test runner. Unfortunately it's not
> > > > easily
> > > > usable on other architectures, since a guest needs to access
> > > > address_space_io, which may not be as straightforward as on
> > > > x86.
> > > > Also, it requires adding ISA bus, which an architecture might
> > > > not
> > > > otherwise need.
> > > >
> > > > Introduce mmio-debug-exit device, which has the same semantics,
> > > > but
> > > > is
> > > > triggered by writes to memory.
> > > >
> > > > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> > >
> > > You shouldn't need this for s390x, as there are already (at
> > > least)
> > > two other paths to
> > > qemu_system_shutdown_request.
> > >
> > > E.g. SIGP, which has a stop option.
> > >
> > >
> > > r~
> > >
> >
> > I would normally use lpswe + disabled wait, but this always gives
> > me
> > exit status code 0, which doesn't allow easily distinguishing
> > between
> > success and failure.
> >
> > Code-wise SIGP seems to do roughly the same thing, and a quick
> > experiment with:
> >
> > lgfi %r4,-1
> > lgfi %r5,-1
> > larl %r6,_cpuaddr
> > stap 0(%r6)
> > lh %r6,0(%r6)
> > nilh %r6,0
> > sigp %r4,%r6,5
> > _cpuaddr: .short 0
> >
> > confirmed that we get exit status code 0 as well.
>
> disabled wait should trigger a qemu_system_guest_panicked().
>
> But "panic_action == PANIC_ACTION_SHUTDOWN" seems to only make
> qemu_main_loop() return with main_loop_should_exit() == true.
>
> main/qemu_main will always return 0.
>
> We could return != 0 on guest panic, but not sure if that could break
> existing scripts. We'd need a new QEMU toggle for that most probably
> ...
>
I wonder if a device is a cleaner way to solve this? It may be used on
all architectures, so there is no need to invent per-architecture way
to exit with a specific code. Maybe we can even replace Intel's
debugexit with it.
[PATCH 3/3] tests/tcg/s390x: Test unaligned accesses to lowcore, Ilya Leoshkevich, 2022/07/11