linux-kernel - Re: [GIT PULL] Native Linux KVM tool for 3.1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E2D6C9A.0@codemonkey.ws>
Date:	Mon, 25 Jul 2011 08:16:10 -0500
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Paolo Bonzini <pbonzini@...hat.com>
CC:	Sasha Levin <levinsasha928@...il.com>,
	Jan Kiszka <jan.kiszka@....de>,
	Pekka Enberg <penberg@...nel.org>, mingo@...e.hu,
	avi@...hat.com, linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	gorcunov@...il.com, asias.hejun@...il.com, prasadjoshi124@...il.com
Subject: Re: [GIT PULL] Native Linux KVM tool for 3.1

On 07/25/2011 07:59 AM, Paolo Bonzini wrote:
> On 07/25/2011 09:50 AM, Sasha Levin wrote:
>> Anthony had a talk on last years KVM forum regarding the QEMU threading
>> model (slide:
>> http://www.linux-kvm.org/wiki/images/7/70/2010-forum-threading-qemu.pdf)
>> .
>>
>> It was suggested that the KVM part of QEMU is having a hard time
>> achieving the ideal threading model due to its need to support TCG -
>> something which has nothing to do with KVM itself.
>
> No, it is not having a hard time. The "foot in the door" that Anthony
> mentions has been part of QEMU and qemu-kvm for a long time
> (multi-threading is necessary to support SMP!) and works quite well.
>
>
> Historically, there were three main loops:
>
> 1) QEMU single-threaded;
>
> 2) QEMU multi-threaded; clean, but buggy, untested and bitrotting;
>
> 3) qemu-kvm multi-threaded, forked from (1), ugly but robust and widely
> deployed.
>
> In 0.15 the two multi-threaded versions have been unified by Jan Kiszka.
> I have even ported (2) to Windows with little or no pain; porting to Mac
> OS X interestingly is harder than Windows, because non-portable Linux
> assumptions about signal handling have crept in the code (to preempt the
> objections: they weren't just non-portabilities, they were latent bugs).
> Windows just does not have signals. :)
>
> So, right now, the only difference is that QEMU is still defaulting to
> the single-threaded main loop, while qemu-kvm enables multi-threading by
> default. In some time even QEMU will switch.
>
> Yes, this is of course worse than getting it right in the first place;
> Nobody is saying the opposite.

In all fairness, the fact that TCG requires signals to break execution 
does complicate the QEMU code a fair bit.  But that's because signals 
are tricky to get right, not that the model is fundamentally complicated.

Regards,

Anthony Liguori

>
> Paolo
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/