From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NN7kA-0006PD-2p for qemu-devel@nongnu.org; Tue, 22 Dec 2009 11:37:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NN7k5-0006LM-6n for qemu-devel@nongnu.org; Tue, 22 Dec 2009 11:37:53 -0500 Received: from [199.232.76.173] (port=39438 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NN7k5-0006LG-01 for qemu-devel@nongnu.org; Tue, 22 Dec 2009 11:37:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:15403) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NN7jx-0003Q7-EP for qemu-devel@nongnu.org; Tue, 22 Dec 2009 11:37:48 -0500 Date: Tue, 22 Dec 2009 18:34:38 +0200 From: "Michael S. Tsirkin" Message-ID: <20091222163437.GE18676@redhat.com> References: <20091208161818.GA32188@redhat.com> <20091222112601.GA16053@redhat.com> <4B30DCFF.8050305@codemonkey.ws> <200912221625.33126.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200912221625.33126.paul@codesourcery.com> Subject: [Qemu-devel] Re: [PATCH-RFC 0/3] qemu: memory barriers in virtio List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Rusty Russell , qemu-devel@nongnu.org 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