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: David Hildenbrand
Subject: Re: [PATCH 2/3] hw/misc: Add mmio-debug-exit device
Date: Tue, 12 Jul 2022 12:08:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

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

-- 
Thanks,

David / dhildenb




reply via email to

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