From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NN7Ye-000395-8a for qemu-devel@nongnu.org; Tue, 22 Dec 2009 11:26:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NN7YY-000387-PK for qemu-devel@nongnu.org; Tue, 22 Dec 2009 11:25:59 -0500 Received: from [199.232.76.173] (port=55269 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NN7YY-000384-Ln for qemu-devel@nongnu.org; Tue, 22 Dec 2009 11:25:54 -0500 Received: from mx20.gnu.org ([199.232.41.8]:18366) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NN7YU-0002AP-Mu for qemu-devel@nongnu.org; Tue, 22 Dec 2009 11:25:54 -0500 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NN7YJ-0008UM-4j for qemu-devel@nongnu.org; Tue, 22 Dec 2009 11:25:39 -0500 From: Paul Brook Date: Tue, 22 Dec 2009 16:25:32 +0000 References: <20091208161818.GA32188@redhat.com> <20091222112601.GA16053@redhat.com> <4B30DCFF.8050305@codemonkey.ws> In-Reply-To: <4B30DCFF.8050305@codemonkey.ws> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <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: Anthony Liguori Cc: Rusty Russell , qemu-devel@nongnu.org, "Michael S. Tsirkin" 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