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

[Scott Tsai <scottt.tw@gmail.com>]

On Wed, Nov 11, 2009 at 10:08 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Wed, Nov 11, 2009 at 01:45:35PM +0000, Paul Brook wrote:
>> If you don't need real barriers, then why does the kvm code have them?
>
> We need real barriers but AFAIK kvm does not have them :(
> IOW: virtio is currently broken with kvm, and my patch did
> not fix this. The comment that I added says as much.

How about just using GCC's __sync__synchronize atomic builtin (if
detected as available by configure)?
It's a full memory barrier instead of just a write barrier,  for x86,
it generates the same code as the current Linux mb() implementation:
"mfence" on x86_64
"lock orl $0x0,(%esp)" on x86 unless -march is specified to a
processor with "mfence".
PPC could continue to use "eieio" while other architectures could just
default to __sync_synchronize

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