From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54555) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TWjkk-0007sg-7u for qemu-devel@nongnu.org; Fri, 09 Nov 2012 03:15:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TWjkd-0004BN-Us for qemu-devel@nongnu.org; Fri, 09 Nov 2012 03:15:50 -0500 Received: from mout.web.de ([212.227.15.4]:61748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TWjkd-0004BJ-GH for qemu-devel@nongnu.org; Fri, 09 Nov 2012 03:15:43 -0500 Message-ID: <509CBBA8.2000800@web.de> Date: Fri, 09 Nov 2012 09:15:36 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1352093924-17598-1-git-send-email-qemulist@gmail.com> <50976419.4010605@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1C63A1967DB77046B2962DFF" Subject: Re: [Qemu-devel] [PATCH v6 0/8] push mmio dispatch out of big lock List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: Peter Maydell , Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Avi Kivity , Anthony Liguori , Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1C63A1967DB77046B2962DFF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-11-09 07:23, liu ping fan wrote: > Ping? Any further comments? >=20 Don't expect too much feedback these days. Folks are busy listening to KVM forum talks, doing networking, enjoying Barcelona and curing their hangovers. ;) Anyway, while hacking my talk it became clearer to me that one of the bigger issues remaining is with the ref/unref callbacks. I don't think we want that much boilerplate code in the device models that this approach implies. The idea I had so far on this is to go back to registering a QOM object reference with the access callbacks and reference it in the generic code directly instead of letting the device models do this. We could introduce= struct MemoryRegionOps { uint64_t (*read)(void *opaque, hwaddr addr, unsigned size); uint64_t (*read_unlocked)(QObject *object, hwaddr addr, unsigned size); void (*write)(void *opaque, hwaddr addr, uint64_t data, unsigned size); void (*write_unlocked)(QObject *object, hwaddr addr, uint64_t data, unsigned size); So, device models supporting the lock-less mode would implement the *_unlocked callbacks, all the rest stay with the simple read/write versions, leaving the new ones NULL. It's an early idea, not fully thought through yet. Jan --------------enig1C63A1967DB77046B2962DFF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCcu6sACgkQitSsb3rl5xQ61ACg0iOpkLcc82be2QoTMKy5b0AO s6oAn3ZzLhAH0Ym415okw06nVHgZU/A3 =yRo8 -----END PGP SIGNATURE----- --------------enig1C63A1967DB77046B2962DFF--