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: <4E2D6896.5010008@redhat.com>
Date:	Mon, 25 Jul 2011 14:59:02 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Sasha Levin <levinsasha928@...il.com>
CC:	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 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.

Paolo
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ