[Qemu-devel] Re: [PATCH-RFC 0/3] qemu: memory barriers in virtio

[Paul Brook]

> > > So possibly this means that we
> > > could optimize the barrier away, but I don't think this amounts to a
> > > serious issue, I guess portability/readability is more important.
> >
> > The more important issue is that regular devices which to not require
> > coherency or ordering can omit this lock.
> >
> So let them. What's the issue?

The issue is that at you're only fixing half the problem. Barriers aren't 
sufficient to get the semantics you need. You also need atomicity.

Given we need both, why not actually defined an API that gives you this? As 
shown with the stw issue, following the linux API is liable to introduce 
subtle bugs that don't exist in a native kernel environment.

By far the simplest solution is to provide atomic, strictly ordered access to 
guest memory. Anything else adds significant complication[1], and is purely a 
performance optimization. I'm not convinced that partial barriers are worth 
the effort.

Paul