From: "Michael S. Tsirkin" <mst@redhat.com>
To: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: Ani Sinha <anisinha@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
qemu-block@nongnu.org,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
Sriram Yagnaraman <sriram.yagnaraman@est.tech>,
Jason Wang <jasowang@redhat.com>, Keith Busch <kbusch@kernel.org>,
Klaus Jensen <its@irrelevant.dk>
Subject: Re: [PATCH] hw/pci: Warn when ARI/SR-IOV device has non-zero Function number
Date: Wed, 12 Jul 2023 07:46:58 -0400 [thread overview]
Message-ID: <20230712073523-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20230712112732.18617-1-akihiko.odaki@daynix.com>
On Wed, Jul 12, 2023 at 08:27:32PM +0900, Akihiko Odaki wrote:
> Current SR/IOV implementations assume that hardcoded Function numbers
> are always available and will not conflict. It is somewhat non-trivial
> to make the Function numbers to use controllable to avoid Function
> number conflicts so ensure there is only one PF to make the assumption
> hold true.
> Also warn when non-SR/IOV multifunction was attempted with ARI enabled;
> ARI has the next Function number field register, and currently it's
> hardcoded to 0, which prevents non-SR/IOV multifunction. It is
> certainly possible to add a logic to determine the correct next Function
> number according to the configuration, but it's not worth since all
> ARI-capable devices are also SR/IOV devices, which do not support
> multiple PFs as stated above.
>
> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
I am not really interested in adding this stuff.
The real thing to focus on is fixing ARI emulation, not
warning users about ways in which it's broken.
> ---
> hw/pci/pci.c | 59 +++++++++++++++++++++++++++++++++++++---------------
> 1 file changed, 42 insertions(+), 17 deletions(-)
>
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 784c02a182..50359a0f3a 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -2124,23 +2124,48 @@ static void pci_qdev_realize(DeviceState *qdev, Error **errp)
> }
> }
>
> - /*
> - * A PCIe Downstream Port that do not have ARI Forwarding enabled must
> - * associate only Device 0 with the device attached to the bus
> - * representing the Link from the Port (PCIe base spec rev 4.0 ver 0.3,
> - * sec 7.3.1).
> - * With ARI, PCI_SLOT() can return non-zero value as the traditional
> - * 5-bit Device Number and 3-bit Function Number fields in its associated
> - * Routing IDs, Requester IDs and Completer IDs are interpreted as a
> - * single 8-bit Function Number. Hence, ignore ARI capable devices.
> - */
> - if (pci_is_express(pci_dev) &&
> - !pcie_find_capability(pci_dev, PCI_EXT_CAP_ID_ARI) &&
> - pcie_has_upstream_port(pci_dev) &&
> - PCI_SLOT(pci_dev->devfn)) {
> - warn_report("PCI: slot %d is not valid for %s,"
> - " parent device only allows plugging into slot 0.",
> - PCI_SLOT(pci_dev->devfn), pci_dev->name);
> + if (pci_is_express(pci_dev)) {
> + /*
> + * A PCIe Downstream Port that do not have ARI Forwarding enabled must
> + * associate only Device 0 with the device attached to the bus
> + * representing the Link from the Port (PCIe base spec rev 4.0 ver 0.3,
> + * sec 7.3.1).
> + * With ARI, PCI_SLOT() can return non-zero value as the traditional
> + * 5-bit Device Number and 3-bit Function Number fields in its
> + * associated Routing IDs, Requester IDs and Completer IDs are
> + * interpreted as a single 8-bit Function Number. Hence, ignore ARI
> + * capable devices.
> + */
> + if (!pcie_find_capability(pci_dev, PCI_EXT_CAP_ID_ARI) &&
> + pcie_has_upstream_port(pci_dev) &&
> + PCI_SLOT(pci_dev->devfn)) {
> + warn_report("PCI: slot %d is not valid for %s,"
> + " parent device only allows plugging into slot 0.",
> + PCI_SLOT(pci_dev->devfn), pci_dev->name);
> + }
> +
> + /*
> + * Current SR/IOV implementations assume that hardcoded Function numbers
> + * are always available. Ensure there is only one PF to make the
> + * assumption hold true.
> + */
> + if (pcie_find_capability(pci_dev, PCI_EXT_CAP_ID_SRIOV) &&
> + PCI_FUNC(pci_dev->devfn)) {
> + warn_report("PCI: function %d is not valid for %s,"
> + " currently PF can only be assigned to function 0.",
> + PCI_FUNC(pci_dev->devfn), pci_dev->name);
> + }
> +
> + /*
> + * ARI has the next Function number field register, and currently it's
> + * hardcoded to 0, which prevents non-SR/IOV multifunction.
> + */
> + if (pcie_find_capability(pci_dev, PCI_EXT_CAP_ID_ARI) &&
> + !pci_is_vf(pci_dev) && (pci_dev->devfn & 0xff)) {
> + warn_report("PCI: function %d is not valid for %s,"
> + " non-SR/IOV multifunction is not supported with ARI enabled.",
> + pci_dev->devfn & 0xff, pci_dev->name);
> + }
> }
>
> if (pci_dev->failover_pair_id) {
> --
> 2.41.0
next prev parent reply other threads:[~2023-07-12 11:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-12 11:27 [PATCH] hw/pci: Warn when ARI/SR-IOV device has non-zero Function number Akihiko Odaki
2023-07-12 11:46 ` Michael S. Tsirkin [this message]
2023-07-12 11:50 ` Akihiko Odaki
2023-07-12 12:06 ` Michael S. Tsirkin
2023-07-13 13:32 ` Akihiko Odaki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230712073523-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=akihiko.odaki@daynix.com \
--cc=anisinha@redhat.com \
--cc=its@irrelevant.dk \
--cc=jasowang@redhat.com \
--cc=kbusch@kernel.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sriram.yagnaraman@est.tech \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.