I've been investigating a race condition where sometimes when my
guest writes to a device register which triggers a
qemu_system_reset_request(), it doesn't actually cause a clean reset,
but instead the guest CPU continues to execute instructions.
I managed to repro it under 'rr', which let me walk
Peter Maydell writes:
> I've been investigating a race condition where sometimes when my
> guest writes to a device register which triggers a
> qemu_system_reset_request(), it doesn't actually cause a clean reset,
> but instead the guest CPU continues to execute instructions.
> I managed to rep
On 1 October 2018 at 19:12, Alex Bennée wrote:
> I would have thought the reset code should be scheduled via safe async
> work to run in the vCPU context. Why should the main loop get involved
> at all here?
The reset code is much older than the safe-async support for
running things in the vCPU c
On 02/10/2018 10:01, Peter Maydell wrote:
> On 1 October 2018 at 19:12, Alex Bennée wrote:
>> I would have thought the reset code should be scheduled via safe async
>> work to run in the vCPU context. Why should the main loop get involved
>> at all here?
> The reset code is much older than the saf
On 2 October 2018 at 09:58, Paolo Bonzini wrote:
>
> First, the reset code should indeed use run_on_cpu (it need not be safe
> i.e. stop-the-world; just run it in the vCPU thread). It certainly
> doesn't do this right now.
I don't understand this part. We're resetting the entire world:
surely we
On 02/10/2018 11:04, Peter Maydell wrote:
> On 2 October 2018 at 09:58, Paolo Bonzini wrote:
>>
>> First, the reset code should indeed use run_on_cpu (it need not be safe
>> i.e. stop-the-world; just run it in the vCPU thread). It certainly
>> doesn't do this right now.
>
> I don't understand th
Peter Maydell writes:
> On 1 October 2018 at 19:12, Alex Bennée wrote:
>> I would have thought the reset code should be scheduled via safe async
>> work to run in the vCPU context. Why should the main loop get involved
>> at all here?
>
> The reset code is much older than the safe-async suppor
On 2 October 2018 at 11:00, Alex Bennée wrote:
>
> Peter Maydell writes:
>
>> On 1 October 2018 at 19:12, Alex Bennée wrote:
>>> I would have thought the reset code should be scheduled via safe async
>>> work to run in the vCPU context. Why should the main loop get involved
>>> at all here?
>>
>
On 2 October 2018 at 10:59, Paolo Bonzini wrote:
> On 02/10/2018 11:04, Peter Maydell wrote:
>> On 2 October 2018 at 09:58, Paolo Bonzini wrote:
>>>
>>> First, the reset code should indeed use run_on_cpu (it need not be safe
>>> i.e. stop-the-world; just run it in the vCPU thread). It certainly
On 02/10/2018 12:34, Peter Maydell wrote:
> On 2 October 2018 at 10:59, Paolo Bonzini wrote:
>> On 02/10/2018 11:04, Peter Maydell wrote:
>>> On 2 October 2018 at 09:58, Paolo Bonzini wrote:
First, the reset code should indeed use run_on_cpu (it need not be safe
i.e. stop-the-world
On 2 October 2018 at 17:46, Paolo Bonzini wrote:
> On 02/10/2018 12:34, Peter Maydell wrote:
>> Maybe I just don't understand what you're suggesting should be
>> done via run-on-cpu. But it seems to me that the problem here
>> is that cpu_stop_current() should not call qemu_cpu_stop()
>> immediate
11 matches
Mail list logo
