From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38587) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMHfM-0008JK-6m for qemu-devel@nongnu.org; Wed, 18 Sep 2013 09:19:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VMHfG-0001sL-3F for qemu-devel@nongnu.org; Wed, 18 Sep 2013 09:19:36 -0400 Received: from mail-lb0-f175.google.com ([209.85.217.175]:57190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMHfF-0001sC-SS for qemu-devel@nongnu.org; Wed, 18 Sep 2013 09:19:30 -0400 Received: by mail-lb0-f175.google.com with SMTP id y6so6618774lbh.34 for ; Wed, 18 Sep 2013 06:19:29 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <5239A693.2070409@redhat.com> References: <20130917162928.GA20672@redhat.com> <52388A3D.4090909@redhat.com> <20130917170752.GA20986@redhat.com> <52388E5F.6020802@redhat.com> <20130917172627.GA21064@redhat.com> <5238A859.9040705@redhat.com> <20130917195123.GB21419@redhat.com> <5238D18B.6020901@redhat.com> <20130918054848.GB23532@redhat.com> <523958E3.6020906@redhat.com> <20130918084138.GA31069@redhat.com> <52398DD8.3050805@redhat.com> <5239A693.2070409@redhat.com> From: Peter Maydell Date: Wed, 18 Sep 2013 22:19:07 +0900 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v2 00/38] Delay destruction of memory regions to instance_finalize List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: QEMU Developers , "Michael S. Tsirkin" On 18 September 2013 22:11, Paolo Bonzini wrote: > Il 18/09/2013 13:56, Peter Maydell ha scritto: >>> > But does guest code actually care? In many cases, I suspect that >>> > sticking a smp_rmb() in the read side of "unlocked" register accesses, >>> > and a smp_wmb() in the write side, will do just fine. And add a >>> > compatibility property to place a device back under the BQL for guests >>> > that have problems. >> Yuck. This sounds like a recipe for spending the next five years >> debugging subtle race conditions. We need to continue to support >> the semantics that the architecture and hardware specs define >> for memory access orderings to emulated devices. > > We cannot in the general case, QEMU is not a cycle-exact simulator. This isn't a cycle-accuracy issue (unsurprisingly, since bus specs and architecture barrier definitions are written to work with multiple implementations of the same CPU). > There's nothing magic, really. Both PV and real devices have been doing > it forever by placing some registers in RAM instead of MMIO, and > communicating synchronization points via interrupts and doorbell registers. Sure, but that's a hardware design choice, it's different from ripping out the assumptions about device behaviour from underneath an existing driver. -- PMM