From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NI2oP-0004rm-H1 for qemu-devel@nongnu.org; Tue, 08 Dec 2009 11:21:17 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NI2oK-0004mm-O9 for qemu-devel@nongnu.org; Tue, 08 Dec 2009 11:21:16 -0500 Received: from [199.232.76.173] (port=38392 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NI2oK-0004mT-E7 for qemu-devel@nongnu.org; Tue, 08 Dec 2009 11:21:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:19722) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NI2oJ-0002eu-RX for qemu-devel@nongnu.org; Tue, 08 Dec 2009 11:21:12 -0500 Date: Tue, 8 Dec 2009 18:18:18 +0200 From: "Michael S. Tsirkin" Message-ID: <20091208161818.GA32188@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] [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: qemu-devel@nongnu.org, Anthony Liguori , Paul Brook 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. This is still under test ... meanwhile: any early feedback/flames? -- MST Michael S. Tsirkin (3): qemu: add barriers.h header virtio: use a real wmb virtio: add missing barriers hw/barriers.h | 131 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ hw/virtio.c | 18 ++++---- 2 files changed, 139 insertions(+), 10 deletions(-) create mode 100644 hw/barriers.h