From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51174) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sdl2i-00041g-DC for qemu-devel@nongnu.org; Sun, 10 Jun 2012 12:31:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sdl2g-0005T1-FF for qemu-devel@nongnu.org; Sun, 10 Jun 2012 12:31:07 -0400 Received: from mout.web.de ([212.227.17.11]:50830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sdl2g-0005Sx-5i for qemu-devel@nongnu.org; Sun, 10 Jun 2012 12:31:06 -0400 Message-ID: <4FD4CBC3.7040300@web.de> Date: Sun, 10 Jun 2012 18:30:59 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4FD0C459.7070104@web.de> <20120607162850.GA12884@redhat.com> <4FD0DAEE.2040405@web.de> <20120610095507.GD6250@redhat.com> <4FD47217.7020909@web.de> <20120610104120.GF6250@redhat.com> <4FD47BA7.7030606@web.de> <1339337968.26976.212.camel@ul30vt> <20120610144301.GC8922@redhat.com> <1339341906.26976.254.camel@ul30vt> <20120610155551.GB9516@redhat.com> In-Reply-To: <20120610155551.GB9516@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig93651B5D840453DA17D6A23F" Subject: Re: [Qemu-devel] [PATCH 05/13] pci: Add pci_device_route_intx_to_irq List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Alexey Kardashevskiy , Alex Williamson , qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig93651B5D840453DA17D6A23F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-06-10 17:55, Michael S. Tsirkin wrote: >>> So if you expect me to merge this work, then either Jan does (1), or >>> gives up and does (2), or I find some time and do (1), or I fail to d= o >>> (1) and get convinced that we need to do (3). Or someone else gets >>> involved. >> >> I still have trouble seeing how (3) is a problem. The translation of = an >> INTx to an irq is chipset specific. We need a chipset function to >> perform that transform. We don't know how to do this for every chipse= t >> in the tree, nor do many of those chipset care at the moment about >> device assignment. Jan has created an arrangement where chipsets can >> easily opt-in to this support. Aside from asking us to go spend a mon= th >> digging up specs for every chipset in tree and trying to implement thi= s >> ourselves, what kind of enhancement to the interface are you looking >> for? Thanks, >> >> Alex >=20 > Sorry I don't understand what you are talking about. > It's better to have one way to determine interrupt routing than two. > It can be done, and IIUC Jan doesn't disagree. > There are gnarly issues related to migration compatibility > with old qemu sorrounding the solution which makes Jan think it's too c= omplex, > but nothing remotely related to digging up any specs. Caching the host bridge generically means changing all chipsets and, well, also testing that they still work afterward. As explained before, I'd really like to avoid doing this in a single step. And there are still migration issues - as explained based on the PIIX3. Until it is officially stated that we give up on backward migratability, it will be quite some effort (ie. lots of additional code) to provide compatibility on top of generic intx-to-irq routing. This interface here is surely not the perfect solution. But it is better than a) hacking device assignment and VFIO into a specific chipset and b) starting a huge refactoring now. We can surely tweak some aspects of this approach before merging, e.g. documentation. But lets try to move forward in small, well testable steps. I really don't see the need for touching all chipsets and migration formats for this purpose ATM. Jan --------------enig93651B5D840453DA17D6A23F 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://enigmail.mozdev.org/ iEYEARECAAYFAk/Uy8YACgkQitSsb3rl5xSR+QCg4YfiR4wPZnSR+IAKgYFBqnW9 D9wAmwYfzowfE0cVdcvwG0CPH3qeyW+r =Y0zr -----END PGP SIGNATURE----- --------------enig93651B5D840453DA17D6A23F--