From patchwork Thu Oct 23 14:26:51 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Williamson X-Patchwork-Id: 402554 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 8AA03140095 for ; Fri, 24 Oct 2014 02:01:09 +1100 (AEDT) Received: from localhost ([::1]:40568 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhJsx-000461-5y for incoming@patchwork.ozlabs.org; Thu, 23 Oct 2014 11:01:07 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhJsS-0003kQ-MA for qemu-devel@nongnu.org; Thu, 23 Oct 2014 11:00:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XhJsM-0000df-Ev for qemu-devel@nongnu.org; Thu, 23 Oct 2014 11:00:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhJsM-0000db-7Z for qemu-devel@nongnu.org; Thu, 23 Oct 2014 11:00:30 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9NF0JZ5009496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 23 Oct 2014 11:00:21 -0400 Received: from [10.3.113.81] (ovpn-113-81.phx2.redhat.com [10.3.113.81]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9NEQpJM005535; Thu, 23 Oct 2014 10:26:51 -0400 Message-ID: <1414074411.27420.14.camel@ul30vt.home> From: Alex Williamson To: Frank Blaschka Date: Thu, 23 Oct 2014 08:26:51 -0600 In-Reply-To: <20141023082140.GA40097@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> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: pbonzini@redhat.com, Frank Blaschka , agraf@suse.de, qemu-devel@nongnu.org Subject: Re: [Qemu-devel] [PATCH] vfio: check if host device supports INTx X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org 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: --- 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;