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: Paul Brook
Subject: [Qemu-devel] Re: [PATCH-RFC 0/3] qemu: memory barriers in virtio
Date: Tue, 22 Dec 2009 16:25:32 +0000
User-agent: KMail/1.12.4 (Linux/2.6.32-trunk-amd64; KDE/4.3.4; x86_64; ; )

On Tuesday 22 December 2009, Anthony Liguori wrote:
> On 12/22/2009 05:26 AM, Michael S. Tsirkin wrote:
> > On Tue, Dec 08, 2009 at 06:18:18PM +0200, Michael S. Tsirkin wrote:
> >> The following fixes a class of long-standing bugs in qemu:
> >> when kvm is enabled, guest might access device structures
> >> in memory while they are updated by qemu on another CPU.
> >> In this scenario, memory barriers are necessary to prevent
> >> host CPU from reordering memory accesses, which might confuse
> >> the guest.
> >>
> >> This patch only fixes virtio, but other emulated devices
> >> might have a similar bug. They'll need to be discovered
> >> and addressed case by case.

Real devices generally aren't cache coherent, so I'd expect problems to be 
rare. I guess theoretically you may need barriers around the MMIO/IO port 
handlers, though in practice the KVM context switch probably provides this 
anyway.

> >> This is still under test ... meanwhile: any early feedback/flames?
> >
> > Any comments on this one?
> > The patch works fine in my testing, and even though
> > it did not fix a crash that I hoped it will fix,
> > it seems required for correctness... Right?
> 
> It's definitely better than what we have.  Rusty mentioned something to
> me a bit ago about the barriers for virtio in the kernel needing some
> work.  I've been meaning to ask him about it in the context of this patch.

Given this is supposed to be portable code, I wonder if we should have atomic 
ordered memory accessors instead.

Paul




reply via email to

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