From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:32832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXDAO-0000iS-8l for qemu-devel@nongnu.org; Sun, 04 Dec 2011 09:35:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXDAM-0002W7-W2 for qemu-devel@nongnu.org; Sun, 04 Dec 2011 09:35:44 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:49650) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXDAM-0002Vy-Dk for qemu-devel@nongnu.org; Sun, 04 Dec 2011 09:35:42 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate02.web.de (Postfix) with ESMTP id EE2961BB1F1CD for ; Sun, 4 Dec 2011 15:35:40 +0100 (CET) Message-ID: <4EDB853A.6050901@web.de> Date: Sun, 04 Dec 2011 15:35:38 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20111204142413.GA21238@redhat.com> In-Reply-To: <20111204142413.GA21238@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC852EA946C8CE9EF900DB130" Subject: Re: [Qemu-devel] [PATCH 4/6] msi: Invoke msi/msix_reset from PCI core List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Isaku Yamahata , Gerd Hoffmann , qemu-devel , Alexander Graf This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC852EA946C8CE9EF900DB130 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-12-04 15:24, Michael S. Tsirkin wrote: > On Sun, Dec 04, 2011 at 02:22:12PM +0100, Jan Kiszka wrote: >> From: Jan Kiszka >> >> There is no point in pushing this burden to the devices, they may rath= er >> forget to call them (like intel-hda and ahci ATM). Instead, reset >> functions are now called from pci_device_reset and pci_bridge_reset. >> They do nothing if the MSI/MSI-X is not in use. >> >> CC: Alexander Graf >> CC: Gerd Hoffmann >> CC: Isaku Yamahata >> Signed-off-by: Jan Kiszka >=20 > What makes me unhappy with this proposal is that msix_write_config, for= > example, becomes in fact an internal interface. So devices should be > calling some functions like msix_init from msix.h, but not others like > msix_write_config. >=20 > It used to be simple: devices should call msix_. > Now, how are devices to figure it out? >=20 > E.g. the comment near msix_write_config says: > /* Handle MSI-X capability config write. */ That should be aligned to msi_write_config's comment. My goal is to reduce the number of calls devices have to do in order to use MSI. We have quite a few correct examples by now, so it should not be too hard to figure out what to do to use standard MSI[X] services. Maybe a PCI skeleton device model would help further. Or up-to-date documentation, thought that may be even harder. ;) >=20 > This puts it at level 11 on Rusty's misuse scale: > Read the documentation and you will get it wrong. >=20 > So I tried writing a wapper, something like pci_capability.h, that woul= d > hide the detail and handle all capabilities seamlessly. Where I got > stuck was migration though, format is ordered so we can't just move the= > fields around. So I decided to wait until we switch to an unordered > format, then it'll become easy. >=20 > Thoughts? MSI-X save/restore is, well, unfortunate. Just like the whole PCI layer in this regard. But I don't think that should block this particular step as it frees device models from an unneeded burden. Jan --------------enigC852EA946C8CE9EF900DB130 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/ iEYEARECAAYFAk7bhToACgkQitSsb3rl5xRcOQCg59+XSx72vOeQGSB0mIoq8+ak NUsAnRY3UcDdt021gK+C2EcBKUinJDFF =o47E -----END PGP SIGNATURE----- --------------enigC852EA946C8CE9EF900DB130--