From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54990) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4p3d-0005yk-32 for qemu-devel@nongnu.org; Fri, 24 Aug 2012 04:15:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T4p3X-0007np-1C for qemu-devel@nongnu.org; Fri, 24 Aug 2012 04:15:57 -0400 Received: from mout.web.de ([212.227.15.4]:65423) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4p3W-0007nc-O5 for qemu-devel@nongnu.org; Fri, 24 Aug 2012 04:15:50 -0400 Message-ID: <50373825.6020007@web.de> Date: Fri, 24 Aug 2012 10:15:33 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <5037182A.7080902@web.de> <20120824081136.GB7830@redhat.com> In-Reply-To: <20120824081136.GB7830@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9E8A59DB63BD80468066D879" Subject: Re: [Qemu-devel] MSI-X bug with ivshmem since msix_reset moved to PCI List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Cam Macdonell , "qemu-devel@nongnu.org Developers" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9E8A59DB63BD80468066D879 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2012-08-24 10:11, Michael S. Tsirkin wrote: > On Fri, Aug 24, 2012 at 07:59:06AM +0200, Jan Kiszka wrote: >> On 2012-08-24 01:13, Cam Macdonell wrote: >>> Hi Jan, >>> >>> I've bisected a bug in which MSI interrupts are not being delivered t= o >>> the following patch, where msix_reset was moved in tot he PCI core. >>> >>> commit cbd2d4342b3d42ab33baa99f5b7a23491b5692f2 >>> Author: Jan Kiszka >>> Date: Tue May 15 20:09:56 2012 -0300 >>> >>> msi: Invoke msi/msix_reset from PCI core >>> >>> There is no point in pushing this burden to the devices, they ten= d to >>> forget to call them (like intel-hda, ahci, xhci did). Instead, re= set >>> functions are now called from pci_device_reset. They do nothing i= f >>> MSI/MSI-X is not in use. >>> >>> I've been debugging and it seems that when msix_notify() is triggered= >>> the second test in the "if" fails >>> >>> /* Send an MSI-X message */ >>> void msix_notify(PCIDevice *dev, unsigned vector) >>> { >>> MSIMessage msg; >>> >>> if (vector >=3D dev->msix_entries_nr || !dev->msix_entry_used[vec= tor]) >>> return; >>> >>> =E2=80=A6 >>> } >>> >>> here is some MSI-X debugging statements >>> >>> msix_init >>> IVSHMEM: msix initialized (1 vectors) >>> IVSHMEM: using vector 0 >>> IVSHMEM: ivshmem_reset >>> IVSHMEM: using vector 0 >>> msix_reset >>> msix_free_irq_entries 0x7fd52d1cea20 >>> >>> msix_free_irq_entries() sets dev->msix_entries_nr to 0, so I think it= >>> may be the cause. >> >> I suppose you mean it sets the msix_entry_used array to 0. >> >>> >>> Shouldn't ivshmem's reset (which reenables the vectors) be triggered >>> by the msix_reset? >> >> Actually, the whole msix vector usage tracking is useless today, this >> just shows its downsides (in the absence of benefits). Megasas is >> affected by this problem as well, virtio not as it calls msix_vector_u= se >> during the configuration process the guest driver triggers. >> >> Two options: >> - I can send my removal patch for msix_vector_use/unuse that I was >> only planning for 1.3 so far, and we kill this pitfall earlier. >> - We re-add msix_vector_use calls to the affected device models for >> 1.2 and drop them later again for 1.3 when removing usage tracking.= >> [The third option to keep the usage tracking is a non-option for me. ;= )] >> >> Michael? >=20 > Second option seems more prudent to me. Can you send a patch pls? In fact, it's not as easy. ivshmem already tries to restore the usage flag but fails due to reset handler ordering. I do not see ATM where there is some "enable device" during re-initialization, at least for ivshmem. Haven't checked megasas yet. I tend to think removing is simpler and less risky. Please have a look at the patch I sent earlier. Jan --------------enig9E8A59DB63BD80468066D879 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/ iEYEARECAAYFAlA3OCUACgkQitSsb3rl5xQFjQCfYdfzlVG51CHK7WBTsuYsVt2B eSgAnjlIMcnW6d4YLy20x5qKRV9L3LZm =zJ6J -----END PGP SIGNATURE----- --------------enig9E8A59DB63BD80468066D879--