From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NN8XD-0005aL-Aj for qemu-devel@nongnu.org; Tue, 22 Dec 2009 12:28:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NN8X8-0005Tt-EN for qemu-devel@nongnu.org; Tue, 22 Dec 2009 12:28:34 -0500 Received: from [199.232.76.173] (port=56583 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NN8X8-0005TS-5Q for qemu-devel@nongnu.org; Tue, 22 Dec 2009 12:28:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:25937) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NN8X6-0000XF-UZ for qemu-devel@nongnu.org; Tue, 22 Dec 2009 12:28:29 -0500 Message-ID: <4B3101AF.7020009@redhat.com> Date: Tue, 22 Dec 2009 19:28:15 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH-RFC 0/3] qemu: memory barriers in virtio References: <20091208161818.GA32188@redhat.com> <20091222112601.GA16053@redhat.com> <4B30DCFF.8050305@codemonkey.ws> <200912221625.33126.paul@codesourcery.com> In-Reply-To: <200912221625.33126.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, "Michael S. Tsirkin" On 12/22/2009 06:25 PM, 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. > We're not guaranteed to have a context switch. One thread can update the ring while another consumes it. -- error compiling committee.c: too many arguments to function