From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhbAr-0004lo-Ih for qemu-devel@nongnu.org; Fri, 24 Oct 2014 05:28:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XhbAg-0006wF-3e for qemu-devel@nongnu.org; Fri, 24 Oct 2014 05:28:45 -0400 Received: from e06smtp10.uk.ibm.com ([195.75.94.106]:45765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhbAf-0006vt-Re for qemu-devel@nongnu.org; Fri, 24 Oct 2014 05:28:34 -0400 Received: from /spool/local by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 24 Oct 2014 10:28:31 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 817BE17D8059 for ; Fri, 24 Oct 2014 10:28:30 +0100 (BST) Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s9O9STMp59899980 for ; Fri, 24 Oct 2014 09:28:29 GMT Received: from d06av10.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s9O9STHo001514 for ; Fri, 24 Oct 2014 03:28:29 -0600 Date: Fri, 24 Oct 2014 11:28:28 +0200 From: Frank Blaschka Message-ID: <20141024092828.GA36221@tuxmaker.boeblingen.de.ibm.com> References: <1413990815-40479-1-git-send-email-blaschka@linux.vnet.ibm.com> <1413998231.4202.235.camel@ul30vt.home> <20141023082140.GA40097@tuxmaker.boeblingen.de.ibm.com> <1414074411.27420.14.camel@ul30vt.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1414074411.27420.14.camel@ul30vt.home> Subject: Re: [Qemu-devel] [PATCH] vfio: check if host device supports INTx List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: pbonzini@redhat.com, Frank Blaschka , agraf@suse.de, qemu-devel@nongnu.org On Thu, Oct 23, 2014 at 08:26:51AM -0600, Alex Williamson wrote: > On Thu, 2014-10-23 at 10:21 +0200, Frank Blaschka wrote: > > On Wed, Oct 22, 2014 at 11:17:11AM -0600, Alex Williamson wrote: > > > On Wed, 2014-10-22 at 17:13 +0200, Frank Blaschka wrote: > > > > From: Frank Blaschka > > > > > > > > Let the kernel announce if INTx is available. Yes, there are platforms > > > > (e.g. s390) which do not support INTx. > > > > > > > > Signed-off-by: Frank Blaschka > > > > --- > > > > hw/misc/vfio.c | 18 +++++++++++++++++- > > > > 1 file changed, 17 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c > > > > index d66f3d2..3e9600b 100644 > > > > --- a/hw/misc/vfio.c > > > > +++ b/hw/misc/vfio.c > > > > @@ -109,6 +109,7 @@ typedef struct VFIOVGA { > > > > } VFIOVGA; > > > > > > > > typedef struct VFIOINTx { > > > > + bool available; /* intx available */ > > > > bool pending; /* interrupt pending */ > > > > bool kvm_accel; /* set when QEMU bypass through KVM enabled */ > > > > uint8_t pin; /* which pin to pull for qemu_set_irq */ > > > > @@ -554,7 +555,7 @@ static int vfio_enable_intx(VFIODevice *vdev) > > > > struct vfio_irq_set *irq_set; > > > > int32_t *pfd; > > > > > > > > - if (!pin) { > > > > + if (!pin || !vdev->intx.available) { > > > > return 0; > > > > } > > > > > > > > @@ -4032,6 +4033,21 @@ static int vfio_get_device(VFIOGroup *group, const char *name, VFIODevice *vdev) > > > > vdev->host.function); > > > > } > > > > > > > > + irq_info.index = VFIO_PCI_INTX_IRQ_INDEX; > > > > + ret = ioctl(vdev->fd, VFIO_DEVICE_GET_IRQ_INFO, &irq_info); > > > > + if (ret) { > > > > + /* > > > > + * This can fail for an old kernel or legacy PCI dev > > > > + * we assume intx is available > > > > + */ > > > > > > Is this true? It's unfortunately from an ABI stability standpoint that > > > we weren't calling this, but the ioctl should have always been there and > > > worked. I'd rather error out here than add a fallback if this is just > > > > ok > > > > > paranoia. Note that SR-IOV VFs will also report count=0 but their IRQ > > > pin register will read 0. We do also have the option to virtualize the > > > IRQ pin register for s390 devices which would make them look the same as > > > > sounds interesting, can you elaborate a little bit more on this? > > At what point can we hook in and modify the pci device config space? > > Untested, but I think it would be something like this: > This is great, works perfect and there is no need to do any qemu vfio changes anymore. You can forget about this patch. Thx, Frank > --- a/drivers/vfio/pci/vfio_pci_config.c > +++ b/drivers/vfio/pci/vfio_pci_config.c > @@ -609,6 +609,10 @@ static int __init init_pci_cap_basic_perm(struct perm_bits > > /* Sometimes used by sw, just virtualize */ > p_setb(perm, PCI_INTERRUPT_LINE, (u8)ALL_VIRT, (u8)ALL_WRITE); > + > + /* Virtualize interrupt pin to allow hiding INTx */ > + p_setb(perm, PCI_INTERRUPT_PIN, (u8)ALL_VIRT, (u8)NO_WRITE); > + > return 0; > } > > @@ -1445,6 +1449,9 @@ int vfio_config_init(struct vfio_pci_device *vdev) > *(__le16 *)&vconfig[PCI_DEVICE_ID] = cpu_to_le16(pdev->device); > } > > + if (!IS_ENABLED(CONFIG_VFIO_PCI_INTX)) > + vconfig[PCI_INTERRUPT_PIN] = 0; > + > ret = vfio_cap_init(vdev); > if (ret) > goto out; > >