Commit Graph

6 Commits

Author SHA1 Message Date
Michael S. Tsirkin a821ce5933 virtio: order index/descriptor reads
virtio has the equivalent of:

	if (vq->last_avail_index != vring_avail_idx(vq)) {
		read descriptor head at vq->last_avail_index;
	}

In theory, processor can reorder descriptor head
read to happen speculatively before the index read.
this would trigger the following race:

	host descriptor head read <- reads invalid head from ring
		guest writes valid descriptor head
		guest writes avail index
	host avail index read <- observes valid index

as a result host will use an invalid head value.
This was not observed in the field by me but after
the experience with the previous two races
I think it is prudent to address this theoretical race condition.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2012-04-25 10:53:47 +03:00
Michael S. Tsirkin a281ebc11a virtio: add missing mb() on notification
During normal operation, virtio first writes a used index
and then checks whether it should interrupt the guest
by reading guest avail index/flag values.

Guest does the reverse: writes the index/flag,
then checks the used ring.

The ordering is important: if host avail flag read bypasses the used
index write, we could in effect get this timing:

host avail flag read
		guest enable interrupts: avail flag write
		guest check used ring: ring is empty
host used index write

which results in a lost interrupt: guest will never be notified
about the used ring update.

This actually can happen when using kvm with an io thread,
such that the guest vcpu and qemu run on different host cpus,
and this has actually been observed in the field
(but only seems to trigger on very specific processor types)
with userspace virtio: vhost has the necessary smp_mb()
in place to prevent the regordering, so the same workload stalls
forever waiting for an interrupt with vhost=off but works
fine with vhost=on.

Insert an smp_mb barrier operation in userspace virtio to
ensure the correct ordering.
Applying this patch fixed the race condition we have observed.
Tested on x86_64. I checked the code generated by the new macro
for i386 and ppc but didn't run virtio.

Note: mb could in theory be implemented by __sync_synchronize, but this
would make us hit old GCC bugs. Besides old GCC
not implementing __sync_synchronize at all, there were bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
in this functionality as recently as in 4.3.

As we need asm for rmb,wmb anyway, it's just as well to
use it for mb.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2012-04-25 10:53:46 +03:00
Eric Sunshine 463ce4ae2d qemu-barrier: Fix build failure on PowerPC Mac OS X
qemu-barrier.h tests if macro __powerpc__ is defined, however, the
preprocessor on PowerPC Mac OS X defines only __POWERPC__, not
__powerpc__.  Resolve by testing instead for qemu-provided _ARCH_PPC.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-11-01 11:50:11 -05:00
David Gibson e22517086b Barriers in qemu-barrier.h should not be x86 specific
qemu-barrier.h contains a few macros implementing memory barrier
primitives used in several places throughout qemu.  However, apart
from the compiler-only barrier, the defined wmb() is correct only for
x86, or platforms which are similarly strongly ordered.

This patch addresses the FIXME about this by making the wmb() macro
arch dependent.  On x86, it remains a compiler barrier only, but with
a comment explaining in more detail the conditions under which this is
correct.  On weakly-ordered powerpc, an "eieio" instruction is used,
again with explanation of the conditions under which it is sufficient.

On other platforms, we use the __sync_synchronize() primitive,
available in sufficiently recent gcc (4.2 and after?).  This should
implement a full barrier which will be sufficient on all platforms,
although it may be overkill in some cases.  Other platforms can add
optimized versions in future if it's worth it for them.

Without proper memory barriers, it is easy to reproduce ordering
problems with virtio on powerpc; specifically, the QEMU puts new
element into the "used" ring and then updates the ring free-running
counter.  Without a barrier between these under the right
circumstances, the guest linux driver can receive an interrupt, read
the counter change but find the ring element to be handled still has
an old value, leading to an "id %u is not a head!\n" error message.
Similar problems are likely to be possible with kvm on other weakly
ordered platforms.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-09-23 11:51:05 -05:00
Jan Kiszka 1d93f0f03d Introduce proper compiler barrier
Define barrier() as optimization barrier and replace (potentially
unreliable) asm("") fences.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-07-22 05:52:08 +02:00
Marcelo Tosatti 85199474d0 kvm-all.c: define smp_wmb and use it for coalesced mmio
Acked-by: "Michael S. Tsirkin" <mst@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
2010-02-22 19:04:13 +02:00