qemu-s390x
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]