All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Ani Sinha <anisinha@redhat.com>
Cc: Akihiko Odaki <akihiko.odaki@daynix.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	qemu-block@nongnu.org, Igor Mammedov <imammedo@redhat.com>,
	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 v5 2/2] pcie: Specify 0 for ARI next function numbers
Date: Mon, 10 Jul 2023 05:44:33 -0400	[thread overview]
Message-ID: <20230710054117-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <B82575EB-132B-4B15-B9EC-89B947826367@redhat.com>

On Mon, Jul 10, 2023 at 02:49:55PM +0530, Ani Sinha wrote:
> 
> 
> > On 10-Jul-2023, at 2:46 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > 
> > On Mon, Jul 10, 2023 at 01:21:50PM +0530, Ani Sinha wrote:
> >> 
> >> 
> >>> On 05-Jul-2023, at 7:54 AM, Akihiko Odaki <akihiko.odaki@daynix.com> wrote:
> >>> 
> >>> The current implementers of ARI are all SR-IOV devices. The ARI next
> >>> function number field is undefined for VF according to PCI Express Base
> >>> Specification Revision 5.0 Version 1.0 section 9.3.7.7. The PF should
> >>> end the linked list formed with the field by specifying 0 according to
> >>> section 7.8.7.2.
> >> 
> >> Section 7.8.7.2 ARI Capability Register (Offset 04h), I see only this
> >> 
> >> Next Function Number - This field indicates the Function Number of the next higher numbered Function in the Device, or 00h if there are no higher numbered Functions. Function 0 starts this linked list of Functions.
> >> 
> >> I do not see anything specifically for PF. What am I missing?
> > 
> > This is *only* for PFs.
> 
> I think this covers both SRIOV and non SRIOV cases both. This is a
> general case for all devices, PF or other non-SRIOV capable devices.

"this" being what? I'm talking about the pci spec text
you quoted.

check out the sriov spec:
Next Function Number – VFs are located using First
VF Offset (see Section 3.3.9) and VF Stride (see
Section 3.3.10).



> > There's separate text explaining that
> > VFs use NumVFs VFOffset and VFStride.
> > 
> > 
> >>> 
> >>> For migration, the field will keep having 1 as its value on the old
> >>> virt models.
> >>> 
> >>> Fixes: 2503461691 ("pcie: Add some SR/IOV API documentation in docs/pcie_sriov.txt")
> >>> Fixes: 44c2c09488 ("hw/nvme: Add support for SR-IOV")
> >>> Fixes: 3a977deebe ("Intrdocue igb device emulation")
> >>> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
> >>> ---
> >>> include/hw/pci/pci.h | 2 ++
> >>> hw/core/machine.c    | 1 +
> >>> hw/pci/pci.c         | 2 ++
> >>> hw/pci/pcie.c        | 2 +-
> >>> 4 files changed, 6 insertions(+), 1 deletion(-)
> >>> 
> >>> diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> >>> index e6d0574a29..9c5b5eb206 100644
> >>> --- a/include/hw/pci/pci.h
> >>> +++ b/include/hw/pci/pci.h
> >>> @@ -209,6 +209,8 @@ enum {
> >>>    QEMU_PCIE_CAP_CXL = (1 << QEMU_PCIE_CXL_BITNR),
> >>> #define QEMU_PCIE_ERR_UNC_MASK_BITNR 11
> >>>    QEMU_PCIE_ERR_UNC_MASK = (1 << QEMU_PCIE_ERR_UNC_MASK_BITNR),
> >>> +#define QEMU_PCIE_ARI_NEXTFN_1_BITNR 12
> >>> +    QEMU_PCIE_ARI_NEXTFN_1 = (1 << QEMU_PCIE_ARI_NEXTFN_1_BITNR),
> >>> };
> >>> 
> >>> typedef struct PCIINTxRoute {
> >>> diff --git a/hw/core/machine.c b/hw/core/machine.c
> >>> index 46f8f9a2b0..f0d35c6401 100644
> >>> --- a/hw/core/machine.c
> >>> +++ b/hw/core/machine.c
> >>> @@ -41,6 +41,7 @@
> >>> 
> >>> GlobalProperty hw_compat_8_0[] = {
> >>>    { "migration", "multifd-flush-after-each-section", "on"},
> >>> +    { TYPE_PCI_DEVICE, "x-pcie-ari-nextfn-1", "on" },
> >>> };
> >>> const size_t hw_compat_8_0_len = G_N_ELEMENTS(hw_compat_8_0);
> >>> 
> >>> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> >>> index e2eb4c3b4a..45a9bc0da8 100644
> >>> --- a/hw/pci/pci.c
> >>> +++ b/hw/pci/pci.c
> >>> @@ -82,6 +82,8 @@ static Property pci_props[] = {
> >>>    DEFINE_PROP_UINT32("acpi-index",  PCIDevice, acpi_index, 0),
> >>>    DEFINE_PROP_BIT("x-pcie-err-unc-mask", PCIDevice, cap_present,
> >>>                    QEMU_PCIE_ERR_UNC_MASK_BITNR, true),
> >>> +    DEFINE_PROP_BIT("x-pcie-ari-nextfn-1", PCIDevice, cap_present,
> >>> +                    QEMU_PCIE_ARI_NEXTFN_1_BITNR, false),
> >>>    DEFINE_PROP_END_OF_LIST()
> >>> };
> >>> 
> >>> diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> >>> index 9a3f6430e8..cf09e03a10 100644
> >>> --- a/hw/pci/pcie.c
> >>> +++ b/hw/pci/pcie.c
> >>> @@ -1030,7 +1030,7 @@ void pcie_sync_bridge_lnk(PCIDevice *bridge_dev)
> >>> /* ARI */
> >>> void pcie_ari_init(PCIDevice *dev, uint16_t offset)
> >>> {
> >>> -    uint16_t nextfn = 1;
> >>> +    uint16_t nextfn = dev->cap_present & QEMU_PCIE_ARI_NEXTFN_1 ? 1 : 0;
> >>> 
> >>>    pcie_add_capability(dev, PCI_EXT_CAP_ID_ARI, PCI_ARI_VER,
> >>>                        offset, PCI_ARI_SIZEOF);
> >>> -- 
> >>> 2.41.0
> >>> 
> > 



  reply	other threads:[~2023-07-10  9:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-05  2:24 [PATCH v5 0/2] pcie: Fix ARI next function numbers Akihiko Odaki
2023-07-05  2:24 ` [PATCH v5 1/2] pcie: Use common ARI next function number Akihiko Odaki
2023-07-05  2:24 ` [PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers Akihiko Odaki
2023-07-10  7:51   ` Ani Sinha
2023-07-10  7:53     ` Akihiko Odaki
2023-07-10  7:58       ` Ani Sinha
2023-07-10  9:16     ` Michael S. Tsirkin
2023-07-10  9:19       ` Ani Sinha
2023-07-10  9:44         ` Michael S. Tsirkin [this message]
2023-07-10 10:14           ` Ani Sinha
2023-07-10 12:00             ` Michael S. Tsirkin

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=20230710054117-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=akihiko.odaki@daynix.com \
    --cc=anisinha@redhat.com \
    --cc=imammedo@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.