From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N8I4X-0003dm-69
	for qemu-devel@nongnu.org; Wed, 11 Nov 2009 13:37:37 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N8I4S-0003b1-9v
	for qemu-devel@nongnu.org; Wed, 11 Nov 2009 13:37:36 -0500
Received: from [199.232.76.173] (port=48400 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N8I4Q-0003a4-QY
	for qemu-devel@nongnu.org; Wed, 11 Nov 2009 13:37:30 -0500
Received: from mail-px0-f201.google.com ([209.85.216.201]:54112)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <scottt.tw@gmail.com>) id 1N8I4Q-0004GV-Ek
	for qemu-devel@nongnu.org; Wed, 11 Nov 2009 13:37:30 -0500
Received: by pxi39 with SMTP id 39so1104016pxi.30
	for <qemu-devel@nongnu.org>; Wed, 11 Nov 2009 10:37:27 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <20091111180928.GB31061@redhat.com>
References: <20091026131715.GA25271@redhat.com>
	<200911111301.03427.paul@codesourcery.com>
	<20091111131253.GC23036@redhat.com>
	<200911111345.35249.paul@codesourcery.com>
	<20091111140819.GA29736@redhat.com>
	<ef2f888d0911110918g2c30aba6y765461d2c1737baf@mail.gmail.com>
	<20091111180928.GB31061@redhat.com>
Date: Thu, 12 Nov 2009 02:37:26 +0800
Message-ID: <ef2f888d0911111037mc139dfekfa0a4ea564431a53@mail.gmail.com>
Subject: Re: [Qemu-devel] Re: [PATCH] qemu/virtio: make wmb compiler barrier +
	comments
From: Scott Tsai <scottt.tw@gmail.com>
Content-Type: text/plain; charset=UTF-8
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Paul Brook <paul@codesourcery.com>, qemu-devel@nongnu.org

On Thu, Nov 12, 2009 at 2:09 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> I do have a newbie question, when exactly would vrtio have to handle
>> concurrent access from multiple threads?
>> My current reading of the code suggests:
>> 1. when CONFIG_IOTHREAD is true
>> 2. when CONFIG_KVM is true and the guest machine has multiple CPUs
>
> Right. I don't think CONFIG_IOTHREAD can work correctly
> without kvm though: how would atomics be handled?

I naively imagined it to work like this:
When CONFIG_IOTHREAD is true and CONFIG_KVM is false,
all the tcg CPUs run in the tcg_cpu_thread and device emulation code
runs in io_thread,
so if the tcg translators generate suitable memory barrier
instructions when it sees a "lfence", "sfence", "mfence" instruction
while emulating a x86 or "sync" while emulating a MIPS everything
should work but a quick look at target-*/translate.c suggests memory
barrier instructions are treated as nops.

So maybe --enable-io-thread while --disable-kvm should not be allowed
at configure time.
Does anyone actually ship qemu with CONFIG_IOTHREAD enabled?