From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60951) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X8yvC-0001if-Ag for qemu-devel@nongnu.org; Sun, 20 Jul 2014 17:45:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X8yv6-0001eJ-97 for qemu-devel@nongnu.org; Sun, 20 Jul 2014 17:45:30 -0400 Received: from mout.web.de ([212.227.15.4]:57744) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X8yv5-0001cx-UY for qemu-devel@nongnu.org; Sun, 20 Jul 2014 17:45:24 -0400 Message-ID: <53CC3866.3010605@web.de> Date: Sun, 20 Jul 2014 23:45:10 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <53CAA314.10005@web.de> <20140720194842.GA2536@redhat.com> In-Reply-To: <20140720194842.GA2536@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d578AWHJLV1Spf83e4GFh88P3Rmh7OW3x" Subject: Re: [Qemu-devel] [PATCH] pci: Don't deliver MSI/MSI-X messages if bus master support is off List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d578AWHJLV1Spf83e4GFh88P3Rmh7OW3x Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-07-20 21:48, Michael S. Tsirkin wrote: > On Sat, Jul 19, 2014 at 06:55:48PM +0200, Jan Kiszka wrote: >> From: Jan Kiszka >> >> The spec says (and real HW confirms this) that, if the bus master bit >> is 0, the device will not generate any PCI accesses. MSI and MSI-X >> messages fall among these. >> >> Signed-off-by: Jan Kiszka >=20 > I guess an alternative is for callers to check before > invoking msi_notify. Please note is this is only option > when using e.g. irqfd, so this has some advantages. > Is there a specific device that is affected by this? > I would expect drivers to disable msi before clearing > bus master bit ... This is about emulating conforming behaviour without touching each and every device. I stumbled over this while playing with emulated vs. real Intel HDA. It may not be complete, but I think it's a step forward. Irqfd users apparently have to do this themselves then, I didn't look into this. But all the rest should not open-code this logic. Jan >=20 >> --- >> hw/pci/msi.c | 4 ++++ >> hw/pci/msix.c | 4 ++++ >> 2 files changed, 8 insertions(+) >> >> diff --git a/hw/pci/msi.c b/hw/pci/msi.c >> index a4a3040..36b651b 100644 >> --- a/hw/pci/msi.c >> +++ b/hw/pci/msi.c >> @@ -285,6 +285,10 @@ void msi_notify(PCIDevice *dev, unsigned int vect= or) >> return; >> } >> =20 >> + if (!(pci_get_word(dev->config + PCI_COMMAND) & PCI_COMMAND_MASTE= R)) { >> + return; >> + } >> + >> msg =3D msi_get_message(dev, vector); >> =20 >> MSI_DEV_PRINTF(dev, >> diff --git a/hw/pci/msix.c b/hw/pci/msix.c >> index 5c49bfc..c77ae7d 100644 >> --- a/hw/pci/msix.c >> +++ b/hw/pci/msix.c >> @@ -437,6 +437,10 @@ void msix_notify(PCIDevice *dev, unsigned vector)= >> return; >> } >> =20 >> + if (!(pci_get_word(dev->config + PCI_COMMAND) & PCI_COMMAND_MASTE= R)) { >> + return; >> + } >> + >> msg =3D msix_get_message(dev, vector); >> =20 >> stl_le_phys(&address_space_memory, msg.address, msg.data); >> --=20 >> 1.8.1.1.298.ge7eed54 >> >=20 >=20 --d578AWHJLV1Spf83e4GFh88P3Rmh7OW3x 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 Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPMOGkACgkQitSsb3rl5xTIEgCeIuyfYWglTSHkKDCILvhfgDCR nM8AnjDKhCqVgiMKG6gotcn1bTrVFg5H =xF3d -----END PGP SIGNATURE----- --d578AWHJLV1Spf83e4GFh88P3Rmh7OW3x--