[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread |
Date: |
Mon, 22 Aug 2011 16:08:14 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
On 2011-08-22 16:00, Paolo Bonzini wrote:
> On 08/22/2011 03:50 PM, Peter Maydell wrote:
>>> Enabling the I/O thread by default seems like an important part of
>>> declaring
>>> 1.0. Besides allowing true SMP support with KVM, the I/O thread means
>>> that the
>>> TCG VCPU doesn't have to multiplex itself with the I/O dispatch routines
>>> which
>>> currently requires a (racey) signal based alarm system.
>>
>> Even with iothread it's still signal based (and still racy) -- the only way
>> to get a thread currently executing TCG code to stop doing so is to send it
>> a signal.
>
> It's signal-based, but I'm not sure it's racy when single-threaded. This:
>
> /* ... tb_add_jump ... */
> barrier();
> if (likely(!env->exit_request)) {
>
> in cpu_exec, vs. this in the signal handler:
>
> void cpu_exit(CPUState *env)
> {
> env->exit_request = 1;
> cpu_unlink_tb(env);
> }
>
> together will make sure that only a single basic block is executed after
> an exit request.
>
> The problems with user-level emulation arise from multiple threads
> concurrently execute the tb_add_jump or cpu_unlink_tb operations. My
> knowledge of user-level emulation is approximately zero, but I think it
> should be possible to make the race outcome predictable. That's because
> (1) cpu_unlink_tb is idempotent; (2) you don't really need to do
> anything in cpu_unlink_tb if the other thread is running tb_add_jump,
> because setting env->exit_request will avoid entering the CPU.
Current multi-threaded user mode emulation is just (too) optimistically
designed. But once VCPUs start to use their own TBs and/or TB chains
(maybe it can be beneficial to decouple the translation buffer from the
linking), this problem should go away.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
- Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread, (continued)
- Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread, Anthony Liguori, 2011/08/29
- Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread, Andreas Färber, 2011/08/29
- Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread, Anthony Liguori, 2011/08/29
- Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread, Andreas Färber, 2011/08/29
- Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread, Anthony Liguori, 2011/08/29
- Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread, Jan Kiszka, 2011/08/29
- Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread, Andreas Färber, 2011/08/30
- Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread, Anthony Liguori, 2011/08/30
Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread, Peter Maydell, 2011/08/22