On Tue, Dec 22, 2009 at 04:25:32PM +0000, Paul Brook wrote: > 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
Could you clarify please? The infiniband bits I used as base are very portable, I know they build on a ton of platforms. I just stripped a couple of infiniband specific assumptions from there. Do you suggest we use __sync_synchronize? Unfortunately this is broken or slow on many platforms. I do use it when it seems safe or when we see a platform we don't know about. -- MST