qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v1 7/9] cpus: move icount preparation out of


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC PATCH v1 7/9] cpus: move icount preparation out of tcg_exec_cpu
Date: Tue, 4 Apr 2017 14:37:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0


On 04/04/2017 14:31, Alex Bennée wrote:
> 
> Paolo Bonzini <address@hidden> writes:
> 
>> On 04/04/2017 12:46, Alex Bennée wrote:
>>>> In theory the main-loop should be sequenced before or after vCPU events
>>>> because of the BQL. I'm not sure why this is not currently the case.
>>>
>>> It seems cpu_handle_exception doesn't take the BQL until
>>> replay_exception() has done its thing. This is fixable but the function
>>> is a mess so I'm trying to neaten that up first.
>>
>> Long term neither cpu_handle_exception nor cpu_handle_interrupt need the
>> BQL at all.
> 
> Well for record/replay they might. Otherwise we end up moving the record
> stream on even though a checkpoint might be being written by the
> main-loop.
> 
> As far as the cc->do_interrupt() stuff is concerned it will be guest
> dependant because you could end up in device emulation code down this
> path which must be protected by the BQL - the arm_gic code being a good
> example.

I think recording an event could be split in two parts:

- recording the (icount, event) tuple and getting back a unique event id

- waiting for all events with lower event id to be complete before
starting to process this one

This doesn't require the BQL, you can use a condition variable on
replay_lock (but you do need to unlock/lock the BQL around it if
currently taken).

The complicated part is ensuring that there are no deadlocks where the
I/O thread needs the VCPU thread to proceed, but the VCPU thread is
waiting on the I/O thread's event processing.

Paolo



reply via email to

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