Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp796138pxa; Wed, 12 Aug 2020 13:36:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyLn8dNGgDrRnom/xQ0E44icudsZ1WxyZx6jLGCb+/i8H7iADHm1OojdYIOVoSJAm2gZ3/V X-Received: by 2002:a17:907:42cd:: with SMTP id nz21mr1602689ejb.395.1597264572853; Wed, 12 Aug 2020 13:36:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597264572; cv=none; d=google.com; s=arc-20160816; b=xV1SYt0jPbwXVNcfWkycGvJEbxGia95qHUsWBuNnVQGlt5BIrs8wucMrkUXfy+oRX9 a81wIUkugFx+5IALa7ljmT8sgoh7e0w9tX9n22DRIKE5wD0gyoQebWVT77enSlwqt+ju CETXy8tpy4O15XGWsLoJylqCybLKxQhQK0qLqvE+0qjIelhOFMY93gHoG2Ol1Ayv3xJN wE5OKwl/sKuouw6yK9fDRaPBKGn+0LuohH7LxOLFQVOkvPOQlRrsBphmeI0ALP9k4KVc 9CKdaw+rVksnKMIihCYgCIXk8vaubJo+twwrVS6xCOv0ShZ7V0u7wvEtpF1qTCtTwgOT 9Qgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature; bh=6Nrc8DX2DPQVNxelk2BXjTZZut7+A4fYjP1T2AupKx4=; b=gbT3nNYThJA7hV7QLwpyAznMbihaR59hF9ACMekY/6oGP38OCUNBHdAQi0scmdM5MC CMCk3MSGk5N9GpHQX+8reYLEP6cwkdn4VtwZ9IVWHraAhzU+7kocwMPfA2Kot/D0IKL7 WhEd1WUWF0wLSzusMUYDWmMs65+zatI5SGu8MiHYBeJMg71mXqYPubKVl8x+pBzoVwWJ vMgkHXE7saBj4OWHUxfyqmzfjYWDwM/Q4ZO9CpfGgADgdIFJvc9pxc/lFSpwOGINNRF4 0szv/Qmgy95SbcXsyB2zGtgJFmTlMJVOJ/qvST+vZyo6P9kW+QACAcYOM0Oe3jw8UtTY i5WQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=H8jRFroY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b23si1965260ejb.465.2020.08.12.13.35.49; Wed, 12 Aug 2020 13:36:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=H8jRFroY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726573AbgHLUdE (ORCPT + 99 others); Wed, 12 Aug 2020 16:33:04 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:22543 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726557AbgHLUdE (ORCPT ); Wed, 12 Aug 2020 16:33:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1597264381; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6Nrc8DX2DPQVNxelk2BXjTZZut7+A4fYjP1T2AupKx4=; b=H8jRFroYX42jaNHDaCzpW44IJhu7ET0VEj5j3lL7/eE1lO7TpmoT0mTbOAeVsiPWYlhzEL rtVyy86e5h1bO+55BZlHjpUxZBC8up/fKZCDrwtis4N8fl0NmozfBt1GjppJ0/YLd5xrpK Nfc9wt+3Wy444cu+hSVqO9JOPcgKdRA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-17-nuFdfxTSMGe6KBa0-yNnFw-1; Wed, 12 Aug 2020 16:32:57 -0400 X-MC-Unique: nuFdfxTSMGe6KBa0-yNnFw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B61AD79ED5; Wed, 12 Aug 2020 20:32:55 +0000 (UTC) Received: from x1.home (ovpn-112-71.phx2.redhat.com [10.3.112.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id D9CDA60E1C; Wed, 12 Aug 2020 20:32:54 +0000 (UTC) Date: Wed, 12 Aug 2020 14:32:54 -0600 From: Alex Williamson To: Matthew Rosato Cc: bhelgaas@google.com, schnelle@linux.ibm.com, pmorel@linux.ibm.com, mpe@ellerman.id.au, oohall@gmail.com, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-pci@vger.kernel.org Subject: Re: [PATCH v2] PCI: Introduce flag for detached virtual functions Message-ID: <20200812143254.2f080c38@x1.home> In-Reply-To: <1597260071-2219-2-git-send-email-mjrosato@linux.ibm.com> References: <1597260071-2219-1-git-send-email-mjrosato@linux.ibm.com> <1597260071-2219-2-git-send-email-mjrosato@linux.ibm.com> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 12 Aug 2020 15:21:11 -0400 Matthew Rosato wrote: > s390x has the notion of providing VFs to the kernel in a manner > where the associated PF is inaccessible other than via firmware. > These are not treated as typical VFs and access to them is emulated > by underlying firmware which can still access the PF. After > abafbc55 however these detached VFs were no longer able to work > with vfio-pci as the firmware does not provide emulation of the > PCI_COMMAND_MEMORY bit. In this case, let's explicitly recognize > these detached VFs so that vfio-pci can allow memory access to > them again. > Might as well include a fixes tag too. Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory") You might also extend the sha1 in the log to 12 chars as well, or replace it with a reference to the fixes tag. > Signed-off-by: Matthew Rosato > --- > arch/s390/pci/pci.c | 8 ++++++++ > drivers/vfio/pci/vfio_pci_config.c | 11 +++++++---- > include/linux/pci.h | 1 + > 3 files changed, 16 insertions(+), 4 deletions(-) > > diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c > index 3902c9f..04ac76d 100644 > --- a/arch/s390/pci/pci.c > +++ b/arch/s390/pci/pci.c > @@ -581,6 +581,14 @@ int pcibios_enable_device(struct pci_dev *pdev, int mask) > { > struct zpci_dev *zdev = to_zpci(pdev); > > + /* > + * If we have a VF on a non-multifunction bus, it must be a VF that is > + * detached from its parent PF. We rely on firmware emulation to > + * provide underlying PF details. > + */ > + if (zdev->vfn && !zdev->zbus->multifunction) > + pdev->detached_vf = 1; > + > zpci_debug_init_device(zdev, dev_name(&pdev->dev)); > zpci_fmb_enable_device(zdev); > > diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c > index d98843f..ee45216 100644 > --- a/drivers/vfio/pci/vfio_pci_config.c > +++ b/drivers/vfio/pci/vfio_pci_config.c > @@ -406,7 +406,8 @@ bool __vfio_pci_memory_enabled(struct vfio_pci_device *vdev) > * PF SR-IOV capability, there's therefore no need to trigger > * faults based on the virtual value. > */ > - return pdev->is_virtfn || (cmd & PCI_COMMAND_MEMORY); > + return pdev->is_virtfn || pdev->detached_vf || > + (cmd & PCI_COMMAND_MEMORY); > } > > /* > @@ -420,7 +421,7 @@ static void vfio_bar_restore(struct vfio_pci_device *vdev) > u16 cmd; > int i; > > - if (pdev->is_virtfn) > + if (pdev->is_virtfn || pdev->detached_vf) > return; > > pci_info(pdev, "%s: reset recovery - restoring BARs\n", __func__); > @@ -521,7 +522,8 @@ static int vfio_basic_config_read(struct vfio_pci_device *vdev, int pos, > count = vfio_default_config_read(vdev, pos, count, perm, offset, val); > > /* Mask in virtual memory enable for SR-IOV devices */ > - if (offset == PCI_COMMAND && vdev->pdev->is_virtfn) { > + if ((offset == PCI_COMMAND) && > + (vdev->pdev->is_virtfn || vdev->pdev->detached_vf)) { > u16 cmd = le16_to_cpu(*(__le16 *)&vdev->vconfig[PCI_COMMAND]); > u32 tmp_val = le32_to_cpu(*val); > > @@ -1734,7 +1736,8 @@ int vfio_config_init(struct vfio_pci_device *vdev) > vconfig[PCI_INTERRUPT_PIN]); > > vconfig[PCI_INTERRUPT_PIN] = 0; /* Gratuitous for good VFs */ > - > + } > + if (pdev->is_virtfn || pdev->detached_vf) { > /* > * VFs do no implement the memory enable bit of the COMMAND > * register therefore we'll not have it set in our initial > diff --git a/include/linux/pci.h b/include/linux/pci.h > index 8355306..23a6972 100644 > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -445,6 +445,7 @@ struct pci_dev { > unsigned int is_probed:1; /* Device probing in progress */ > unsigned int link_active_reporting:1;/* Device capable of reporting link active */ > unsigned int no_vf_scan:1; /* Don't scan for VFs after IOV enablement */ > + unsigned int detached_vf:1; /* VF without local PF access */ Is there too much implicit knowledge in defining a "detached VF"? For example, why do we know that we can skip the portion of vfio_config_init() that copies the vendor and device IDs from the struct pci_dev into the virtual config space? It's true on s390x, but I think that's because we know that firmware emulates those registers for us. We also skip the INTx pin register sanity checking. Do we do that because we haven't installed the broken device into an s390x system? Because we know firmware manages that for us too? Or simply because s390x doesn't support INTx anyway, and therefore it's another architecture implicit decision? If detached_vf is really equivalent to is_virtfn for all cases that don't care about referencing physfn on the pci_dev, then we should probably have a macro to that effect. Otherwise, if we're just trying to describe that the memory bit of the command register is unimplemented but always enabled, like a VF, should we specifically describe that attribute instead? If so, should we instead do that with pci_dev_flags_t? Thanks, Alex > pci_dev_flags_t dev_flags; > atomic_t enable_cnt; /* pci_enable_device has been called */ >