qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael S. Tsirkin
Subject: [Qemu-devel] Re: [PATCH-RFC 0/3] qemu: memory barriers in virtio
Date: Wed, 23 Dec 2009 14:16:22 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

On Wed, Dec 23, 2009 at 01:58:04PM +0200, Michael S. Tsirkin wrote:
> > Where does it say that stw_phys is atomic?
> > 
> > By my reading stw_phys is implemented using memcpy. This means that it is 
> > almost certainly not atomic.  My guess is that this works entirely by 
> > chance, 
> > because the window for observing that race condition on cached SMP systems 
> > is 
> > exceedingly small.
> 
> Good point. Also, it is very rare in virtio to change the high byte,
> which makes the window even smaller.  So yes, I suspect it's another
> bug in virtio, unrelated to the barrier issue. Thanks for pointing it
> out!

In theory :) In practice gcc seems to optimize this to a single 16 bit
memory operation, so we are fine.
I agree we should think of an API in qemu making this explicit, though.

> > > > This avoids issues in the future (multithreaded TCG) where atomic memory
> > > > accesses may be nontrivial.
> > > 
> > > Unfortunately I have no real idea how this will work and what the issues
> > > are. I speculate stw_phys, on host platforms that can not write 2 bytes
> > > atomically, will need to take some lock? 
> > 
> > Yes. As mentioned above, I don't believe stw_phys is atomic on any platform.
> 
> That's another bug in virtio then :)

Apparently it is, mostly by luck.

-- 
MST




reply via email to

[Prev in Thread] Current Thread [Next in Thread]