Re: [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default

[Alexander Graf]

On 08.02.2011, at 11:06, Aurelien Jarno wrote:

> Jan Kiszka a écrit :
>> On 2011-02-08 10:58, Aurelien Jarno wrote:
>>> Jan Kiszka a écrit :
>>>> On 2011-02-08 10:05, Aurelien Jarno wrote:
>>>>> Jan Kiszka a écrit :
>>>>>> On 2011-02-08 09:08, Paolo Bonzini wrote:
>>>>>>> On 02/08/2011 08:26 AM, Aurelien Jarno wrote:
>>>>>>>> I forget to remember when we decided that AIO should be implemented on
>>>>>>>> any host OS. Any pointer?
>>>>>>> To be fair, I/O-heavy workloads are almost unusable without AIO.  For 
>>>>>>> Window targets, they also crash under SMP due to the Windows AP 
>>>>>>> watchdog.  But then TCG and SMP do not go very well together anyway.
>>>>>>> 
>>>>>>> However, I think deprecating Win32 support would be a very bad idea.
>>>>>> It would be too early at this point.
>>>>>> 
>>>>>> But if Windows is once the only reason to keep tons of hardly tested
>>>>>> code paths around or to invest significant additional effort to change
>>>>>> logic or interfaces in this area, than I would prefer that step. I'm
>>>>>> hacking on IOTHREAD vs. !IOTHREAD for some weeks now, and all those
>>>>>> subtle differences are really a PITA and source of various breakages.
>>>>>> 
>>>>>> People interested in that platform should finally realize that its fate
>>>>>> is coupled to reducing the #ifdefs as well as the design differences we
>>>>>> see right now and even more in the future.
>>>>>> 
>>>>> The guilty here is IOTHREAD. Windows support predates IOTHREAD concept,
>>>>> it's just that people who introduce IOTHREAD didn't care about Windows
>>>>> support at all and added these #ifdef. Disabling Windows support because
>>>>> of that is not fair.
>>>> The TCG execution model won't scale long-term. It's already a main to
>>>> boot a quad or just dual core VM, even more when your host has at least
>>>> as many real cores. I'm sure we'll see multi-threaded TCG CPUs in the
>>>> future, and the iothread will just be one of 7, 17 or 257 threads.
>>>> 
>>> And what's the issue with that? People don't always look for performance
>>> when using QEMU. They even often try to emulate old machines (and non
>>> x86 ones), which anyway only have one CPU. This won't change in 5 years,
>>> the only thing is that those machines will be 5 years older.
>>> 
>>> People have to keep in mind that QEMU doesn't mean only virtualization
>>> and doesn't mean only x86.
>> 
>> I'm not talking about virtualization here. I'm talking about usable
>> emulation of today's (!) embedded multi-core platforms. It matters a lot
>> if your test roundtrip for booting into a SMP guest and running some
>> apps is a few 10 seconds, a few minutes or even not practically working.
>> Ever tried to boot a 16 core VM in emulation mode? I did, for fun. I
>> just hope I'll never depend on this for work.
> 
> Yes, it's slow. But is it a problem? You assume that people use QEMU
> only for emulating SMP platforms. This is a wrong assumption. Beside the
> x86 target, only sparc really supports SMP emulation.

I guess his point here really is that soon SMP is commodity. Most new ARM cores 
move to SMP by default, MIPS is there already and even embedded PPC is 
multi-core for a while now. Sure, you can work around things by only emulating 
a single core at times, but it's not always good enough - especially if you're 
working on interrupt handling code.

Either way, the whole discussion is moot. We either do support Windows or we 
don't. Most of the developers don't even have windows machines, so it's very 
hard for them to do it - even less so do they have windows programming 
knowledge. So what we really need is for someone to implement the thread 
infrastructure and aio support on windows and then all is great (until the next 
big infrastructure feature of course).

If only the Android people wouldn't simply fork every project out there, but 
work upstream, we'd probably have quite a few folks happy to support windows 
from that crowd, as they depend on it heavily.


Alex