From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZGSf-0008AC-G9 for qemu-devel@nongnu.org; Mon, 06 May 2013 04:07:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZGSd-0007ni-Vp for qemu-devel@nongnu.org; Mon, 06 May 2013 04:07:53 -0400 Received: from mail-ee0-f44.google.com ([74.125.83.44]:46733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZGSd-0007na-MD for qemu-devel@nongnu.org; Mon, 06 May 2013 04:07:51 -0400 Received: by mail-ee0-f44.google.com with SMTP id t10so1584209eei.17 for ; Mon, 06 May 2013 01:07:51 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <518764CD.2080602@redhat.com> Date: Mon, 06 May 2013 10:07:41 +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> In-Reply-To: <5184E601.9030407@web.de> Content-Type: text/plain; charset=ISO-8859-1 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Il 04/05/2013 12:42, Jan Kiszka ha scritto: > On 2013-05-04 11:47, Paolo Bonzini wrote: >> Il 03/05/2013 10:04, Jan Kiszka ha scritto: >>> We can't change the semantics of opaque as long as old_mmio / >>> old_portio are around. But we need a flag anyway to indicate if >>> a region is depending on BQL or not. Adding a separate "Object >>> *owner" to MemoryRegion can serve both purposes. Then we define >>> something like >>> >>> void memory_region_set_local_locking(MemoryRegion *mr, bool >>> local_locking, Object *owner); >>> >>> to control the property (if local_locking is true, owner must >>> be non-NULL, of course). That's quite similar to my old >>> prototype here that had >>> memory_region_set/clear_global_locking. >> >> I think setting the owner can be done separately from enabling >> local lock. For example, memory_region_find could also have a >> variant that adds a ref to the owner. It would be very similar >> to what Ping Fan is doing in the virtio-dataplane's HostMem data >> structure. > > That's trivial to break up, but I'm not sure if there will be > reasonable scenarios where a region requires reference counting > without being able to work without the BQL. RAM, e.g., should > always work BQL-free (once we have the infrastructure in place). I think we need to add an owner to all regions (tedious, but doable---perhaps even scriptable). The current code covers address_space_rw, but memory_region_find remains callable only from BQL-protected regions. The caller of memory_region_find needs to be able to inspect the MemoryRegion, even if it is just to fail on non-RAM regions. I would like to switch the dataplane code to use memory_region_find. BTW, have you seen http://lwn.net/SubscriberLink/548909/b6fdd846f1232be6/ ? [*] Perhaps we can adopt something like that, it solves the same exact problem that we have, and it's a well-known solution from the literature. [*] 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. Paolo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRh2TNAAoJEBvWZb6bTYbyVqsP/3DUCevVyhMU0OsDrdMhtbQO 9fTzQmvhbUo2auEzjhjxvl9YH/2exvymsBH1kW2dM5xsct+MsULKMmpw2wucELfd 9i82fS/TbofTWQI0Qz2iCEn6G40aAJf5GC/eMMUINpYlTL0hhaRibaNl4wtwgM+N FhlohLM0Dki/dQiF+DOfr2TdeFwuJfBpaDVL3Q7YZ+4TXADnjHglltWBwWk0RYvy 1nzUNqah4WwP3yOSlh53kT40VGCgea3mJaogoBTNz1iYdsi2FEGcRdO8JKQqZDoU 0EzfEfBTmACSjXdFOpnkR81PV19DiinRK/Wcj4RGfJJygHAZcabseueWOYKLox+P Zkjvr1h8HBkJWAZB1yZn0M++ts6nByFFZt0RKDgR9DEhJbKlf6E/7yH/xclecSMR UynRjuLIZWmKgs+VrfBE8Sda4Wz8NP8oR6A6rv0t9K+oLI0CAA8bj3fQmGhgldkP AAIyOcsWP7VnizvaLoxicP20fAqvEBPYJhcO80/kVrdubG9yt6ljdHnIwGpbXrR5 hchYoWYK4SsyPp6YwESG1eVPZ/4GNoK0PIjeJELSmUGwbMfwU/VOaIL0DExXpF5Y b9yct9CpgEW3PhGxqCNgEsPAIbMSpl1OjaAqAdDb+DGZiYwIWE8Mb3SB5Ilsvco2 ZYVzJH7sXoOB9o5k7DIt =nA/3 -----END PGP SIGNATURE-----