qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH V7 00/19] Multithread TCG.


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC PATCH V7 00/19] Multithread TCG.
Date: Tue, 11 Aug 2015 16:10:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0


On 11/08/2015 15:59, Frederic Konrad wrote:
>> - tb_lock usage in tb_find_fast is complicated and introduces the need
>> for other complicated code such as the tb_invalidate callback.  Instead,
>> the tb locking should reuse the cpu-exec.c code for user-mode emulation,
>> with additional locking in the spots identified by Fred.
> 
> The reason for this is that locking around tb_find_fast just kills the
> performance.

Let's make it correct first. :)

>> - the whole signal-based qemu_cpu_kick can just go away.  Just setting
>> tcg_exit_req and exit_request will kick the TCG thread.  The hairy Win32
>> SuspendThread/ResumeThread goes away too.  I suggest doing it now,
>> because proving it unnecessary is easier than proving it correct.
> 
> Just setting tcg_exit_req and exit_request and signal the cpu->halt_cond
> I guess?

Yes.

>> - the big QEMU lock is not taken anywhere for MMIO accesses that require
>> it (i.e. basically all of them)
> Isn't that handled by prepare_mmio_access?

That's not used on the TCG path (which calls
memory_region_dispatch_read/write directly).

Paolo



reply via email to

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