[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] qemu_system_reset_request() broken w.r.t BQL locking re
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] qemu_system_reset_request() broken w.r.t BQL locking regime |
Date: |
Wed, 5 Jul 2017 18:21:53 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 |
On 05/07/2017 18:14, Peter Maydell wrote:
>> - Guest resets board, writing to some hw address (e.g.
>> arm_sysctl_write)
>> - This triggers qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET)
>> - We exit iowrite and drop the BQL
>> - vl.c schedules qemu_system_reset->qemu_devices_reset...arm_cpu_reset
>> - we start writing new values to CPU env while still in TCG code
>> - CHAOS!
>>
>> The general solution for this is to ensure these sort of tasks are done
>> with safe work in the CPUs context when we know nothing else is running.
>> It seems this is probably best done by modifying
>> qemu_system_reset_request to queue work up on current_cpu and execute it
>> as safe work - I don't think the vl.c thread should ever be messing
>> about with calling cpu_reset directly.
> My first thought is that qemu_system_reset() should absolutely
> stop every CPU (or other runnable thing like a DMA agent) in the
> system. The semantics are basically "like a power cycle", so
> that should include a complete stop of the world. (Is this
> what vm_stop() does? Dunno...)
I agree, it should do vm_stop() as the first thing and, if applicable,
vm_start() as the last thing, similar to e.g. savevm.
In fact, the above bug probably has existed forever in KVM.
Paolo