From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRJmu-00053z-0D for qemu-devel@nongnu.org; Thu, 25 Oct 2012 05:31:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRJmr-00029q-9L for qemu-devel@nongnu.org; Thu, 25 Oct 2012 05:31:39 -0400 Received: from mout.web.de ([212.227.17.12]:50454) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRJmr-00029G-0Q for qemu-devel@nongnu.org; Thu, 25 Oct 2012 05:31:37 -0400 Message-ID: <508906DC.8090502@web.de> Date: Thu, 25 Oct 2012 11:31:08 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1350897839-29593-1-git-send-email-pingfank@linux.vnet.ibm.com> <1350897839-29593-13-git-send-email-pingfank@linux.vnet.ibm.com> <50865DB9.1060106@siemens.com> <50879606.3070004@web.de> <50890002.90701@redhat.com> In-Reply-To: <50890002.90701@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE8844237E326459F8F30253F" Subject: Re: [Qemu-devel] [patch v4 12/16] e1000: apply fine lock on e1000 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Liu Ping Fan , Stefan Hajnoczi , Marcelo Tosatti , "qemu-devel@nongnu.org" , liu ping fan , Anthony Liguori , Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE8844237E326459F8F30253F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-10-25 11:01, Avi Kivity wrote: > On 10/24/2012 09:17 AM, Jan Kiszka wrote: >>>> >>>> This is ugly for many reasons. First of all, it is racy as the regis= ter >>>> content may change while dropping the device lock, no? Then you woul= d >>>> raise or clear an IRQ spuriously. >>>> >>> Device state's intact is protected by busy flag, and will not broken >> >> Except that the busy flag concept is broken in itself. >=20 > How do we fix an mmio that ends up mmio'ing back to itself, perhaps > indirectly? Note this is broken in mainline too, but in a different wa= y. >=20 > Do we introduce clever locks that can detect deadlocks? That problem is already addressed (to my understanding) by blocking nested MMIO in general. The brokenness of the busy flag is that it prevents concurrent MMIO by dropping requests. >=20 >> I see that we have a all-or-nothing problem here: to address this >> properly, we need to convert the IRQ path to lock-less (or at least >> compatible with holding per-device locks) as well. >=20 > There is a transitional path where writing to a register that can cause= > IRQ changes takes both the big lock and the local lock. >=20 > Eventually, though, of course all inner subsystems must be threaded for= > this work to have value. >=20 But that transitional path must not introduce regressions. Opening a race window between IRQ cause update and event injection is such a thing, just like dropping concurrent requests on the floor. Jan --------------enigE8844237E326459F8F30253F 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.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCJBuwACgkQitSsb3rl5xSdOQCgja3eDld/JH/GJk3f9kGIsgiX qtwAoKa+M4iaAr4l4nEHZtnRfVTJ2mJY =xkhI -----END PGP SIGNATURE----- --------------enigE8844237E326459F8F30253F--