Re: [Qemu-devel] Re: [PATCH] qemu/virtio: make wmb compiler barrier + comments

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Nov 12, 2009 at 02:37:26AM +0800, Scott Tsai wrote:
> 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

that might not be enough. guest can do e.g. atomics on the same memory
with iothread. In parctice, with virtio it doesn't.

> 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?