From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZIe8-0003NA-4p for qemu-devel@nongnu.org; Mon, 06 May 2013 06:27:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZIe7-000496-3C for qemu-devel@nongnu.org; Mon, 06 May 2013 06:27:52 -0400 Received: from mail-yh0-x233.google.com ([2607:f8b0:4002:c01::233]:45327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZIe6-00048S-U8 for qemu-devel@nongnu.org; Mon, 06 May 2013 06:27:51 -0400 Received: by mail-yh0-f51.google.com with SMTP id l109so676589yhq.10 for ; Mon, 06 May 2013 03:27:49 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5187859C.5020305@redhat.com> Date: Mon, 06 May 2013 12:27:40 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1353808984-22368-1-git-send-email-qemulist@gmail.com> <51829B30.7020308@siemens.com> <51836FA8.2000501@siemens.com> <5184D942.5020506@redhat.com> <5184E601.9030407@web.de> <518764CD.2080602@redhat.com> <51876C86.5040301@siemens.com> In-Reply-To: <51876C86.5040301@siemens.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v7 0/7] push mmio dispatch out of big lock List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel , Liu Ping Fan Il 06/05/2013 10:40, Jan Kiszka ha scritto: >> >> [*] The "subscriber link" mechanism allows an LWN.net >> subscriber to generate a special URL for a >> subscription-only article. That URL can then be given to >> others, who will be able to access the article regardless >> of whether they are subscribed. This feature is made >> available as a service to LWN subscribers, and in the hope >> that they will use it to spread the word about their >> favorite LWN articles. >> >>> And memory_region_find should likely always increment a reference >>> if the target region has an owner. We should convert its users to >>> properly dereference the region once done with it. >> >> Yes. But this is what requires you to have an owner for all regions. > > You don't need an owner for regions that are protect by the BQL (the > majority in the foreseeable future). For those regions, reference > counting can remain a nop, internally. The problem is that even if I/O for a region is supposed to happen within the BQL, lookup can happen outside the BQL. Lookup will use the region even if it is just to discard it: VCPU thread (under BQL) device thread -------------------------------------------------------------------------------------- flatview_ref memory_region_find returns d->mr memory_region_ref(d->mr) /* nop */ qdev_free(d) object_unparent(d) unrealize(d) memory_region_del_subregion(d->mr) FlatView updated, d->mr not in the new view flatview_unref memory_region_unref(d->mr) object_unref(d) free(d) if (!d->mr->is_ram) { /* BAD! */ memory_region_unref(d->mr) /* nop */ return error } Here, the memory region is dereferenced *before* we know that it is BQL-free (in fact, exactly to ascertain whether it is BQL-free). We can hack around it by putting an is_ram field in FlatRange and MemoryRegionSection, but it is not a solution. Here is how giving an owner to all regions fixes it: VCPU thread (under BQL) device thread -------------------------------------------------------------------------------------- flatview_ref memory_region_find returns d->mr memory_region_ref(d->mr) object_ref(d) qdev_free(d) object_unparent(d) unrealize(d) memory_region_del_subregion(d->mr) FlatView updated, d->mr not in the new view flatview_unref memory_region_unref(d->mr) object_unref(d) /* still alive! */ if (!d->mr->is_ram) { memory_region_unref(d->mr) object_unref(d) free(d) return error } Paolo