[PATCH v5 0/2] pcie: Fix ARI next function numbers

[PATCH v5 0/2] pcie: Fix ARI next function numbers

[Akihiko Odaki]

The ARI next function number field is undefined for VF. The PF should
end the linked list formed with the field by specifying 0.

Supersedes: <20230701070133.24877-1-akihiko.odaki@daynix.com>
("[PATCH 0/4] pci: Compare function number and ARI next function number")

V4 -> V5:
  Added references to the specification. (Igor Mammedov)

V3 -> V4:
  Corrected the default value of x-pcie-ari-nextfn-1. (Igor Mammedov)
  Added an explanation for migration compatibility. (Igor Mammedov)

V2 -> V3:
  Moved the logic to PCI common infrastucture (Michael S. Tsirkin)

V1 -> V2:
  Fixed migration. (Michael S. Tsirkin)
  Added a caveat comment. (Michael S. Tsirkin)

Akihiko Odaki (2):
  pcie: Use common ARI next function number
  pcie: Specify 0 for ARI next function numbers

 docs/pcie_sriov.txt   | 4 ++--
 include/hw/pci/pci.h  | 2 ++
 include/hw/pci/pcie.h | 2 +-
 hw/core/machine.c     | 1 +
 hw/net/igb.c          | 2 +-
 hw/net/igbvf.c        | 2 +-
 hw/nvme/ctrl.c        | 2 +-
 hw/pci/pci.c          | 2 ++
 hw/pci/pcie.c         | 4 +++-
 9 files changed, 14 insertions(+), 7 deletions(-)

-- 
2.41.0

[PATCH v5 1/2] pcie: Use common ARI next function number

[Akihiko Odaki]

Currently the only implementers of ARI is SR-IOV devices, and they
behave similar. Share the ARI next function number.

Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---
 docs/pcie_sriov.txt   | 4 ++--
 include/hw/pci/pcie.h | 2 +-
 hw/net/igb.c          | 2 +-
 hw/net/igbvf.c        | 2 +-
 hw/nvme/ctrl.c        | 2 +-
 hw/pci/pcie.c         | 4 +++-
 6 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/docs/pcie_sriov.txt b/docs/pcie_sriov.txt
index 7eff7f2703..a47aad0bfa 100644
--- a/docs/pcie_sriov.txt
+++ b/docs/pcie_sriov.txt
@@ -48,7 +48,7 @@ setting up a BAR for a VF.
       ...
       int ret = pcie_endpoint_cap_init(d, 0x70);
       ...
-      pcie_ari_init(d, 0x100, 1);
+      pcie_ari_init(d, 0x100);
       ...
 
       /* Add and initialize the SR/IOV capability */
@@ -78,7 +78,7 @@ setting up a BAR for a VF.
       ...
       int ret = pcie_endpoint_cap_init(d, 0x60);
       ...
-      pcie_ari_init(d, 0x100, 1);
+      pcie_ari_init(d, 0x100);
       ...
       memory_region_init(mr, ... )
       pcie_sriov_vf_register_bar(d, bar_nr, mr);
diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
index 3cc2b15957..bf7dc5d685 100644
--- a/include/hw/pci/pcie.h
+++ b/include/hw/pci/pcie.h
@@ -134,7 +134,7 @@ void pcie_sync_bridge_lnk(PCIDevice *dev);
 void pcie_acs_init(PCIDevice *dev, uint16_t offset);
 void pcie_acs_reset(PCIDevice *dev);
 
-void pcie_ari_init(PCIDevice *dev, uint16_t offset, uint16_t nextfn);
+void pcie_ari_init(PCIDevice *dev, uint16_t offset);
 void pcie_dev_ser_num_init(PCIDevice *dev, uint16_t offset, uint64_t ser_num);
 void pcie_ats_init(PCIDevice *dev, uint16_t offset, bool aligned);
 
diff --git a/hw/net/igb.c b/hw/net/igb.c
index 1c989d7677..8ff832acfc 100644
--- a/hw/net/igb.c
+++ b/hw/net/igb.c
@@ -431,7 +431,7 @@ static void igb_pci_realize(PCIDevice *pci_dev, Error **errp)
         hw_error("Failed to initialize AER capability");
     }
 
-    pcie_ari_init(pci_dev, 0x150, 1);
+    pcie_ari_init(pci_dev, 0x150);
 
     pcie_sriov_pf_init(pci_dev, IGB_CAP_SRIOV_OFFSET, TYPE_IGBVF,
         IGB_82576_VF_DEV_ID, IGB_MAX_VF_FUNCTIONS, IGB_MAX_VF_FUNCTIONS,
diff --git a/hw/net/igbvf.c b/hw/net/igbvf.c
index 284ea61184..d55e1e8a6a 100644
--- a/hw/net/igbvf.c
+++ b/hw/net/igbvf.c
@@ -270,7 +270,7 @@ static void igbvf_pci_realize(PCIDevice *dev, Error **errp)
         hw_error("Failed to initialize AER capability");
     }
 
-    pcie_ari_init(dev, 0x150, 1);
+    pcie_ari_init(dev, 0x150);
 }
 
 static void igbvf_pci_uninit(PCIDevice *dev)
diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
index fd917fcda1..8b7168a266 100644
--- a/hw/nvme/ctrl.c
+++ b/hw/nvme/ctrl.c
@@ -8088,7 +8088,7 @@ static bool nvme_init_pci(NvmeCtrl *n, PCIDevice *pci_dev, Error **errp)
     pcie_endpoint_cap_init(pci_dev, 0x80);
     pcie_cap_flr_init(pci_dev);
     if (n->params.sriov_max_vfs) {
-        pcie_ari_init(pci_dev, 0x100, 1);
+        pcie_ari_init(pci_dev, 0x100);
     }
 
     /* add one to max_ioqpairs to account for the admin queue pair */
diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index b8c24cf45f..9a3f6430e8 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -1028,8 +1028,10 @@ void pcie_sync_bridge_lnk(PCIDevice *bridge_dev)
  */
 
 /* ARI */
-void pcie_ari_init(PCIDevice *dev, uint16_t offset, uint16_t nextfn)
+void pcie_ari_init(PCIDevice *dev, uint16_t offset)
 {
+    uint16_t nextfn = 1;
+
     pcie_add_capability(dev, PCI_EXT_CAP_ID_ARI, PCI_ARI_VER,
                         offset, PCI_ARI_SIZEOF);
     pci_set_long(dev->config + offset + PCI_ARI_CAP, (nextfn & 0xff) << 8);
-- 
2.41.0

[PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers

[Akihiko Odaki]

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.

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

Re: [PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers

[Ani Sinha]

> 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?

> 
> 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
> 

Re: [PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers

[Akihiko Odaki]

On 2023/07/10 16:51, 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?

It's not specific to PF, but in general the linked list of Functions 
needs to end with 0.

> 
>>
>> 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
>>
> 

Re: [PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers

[Ani Sinha]

> On 10-Jul-2023, at 1:23 PM, Akihiko Odaki <akihiko.odaki@daynix.com> wrote:
> 
> On 2023/07/10 16:51, 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?
> 
> It's not specific to PF, but in general the linked list of Functions needs to end with 0.

OK so the language is confusing here. Maybe just say that the next function number should be 00h if there are no higher numbered functions, without saying anything about PF.

> 
>>> 
>>> 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
>>> 
> 

Re: [PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers

[Michael S. Tsirkin]

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. 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
> > 

Re: [PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers

[Ani Sinha]

> 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.

> 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
>>> 
> 

Re: [PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers

[Michael S. Tsirkin]

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
> >>> 
> > 

Re: [PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers

[Ani Sinha]

> On 10-Jul-2023, at 3:14 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> 
> 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?

“this” is the following line I quoted above:

"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 think it applies for all devices in general (except VFs).

> 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
>>>>> 
>>> 
> 

Re: [PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers

[Michael S. Tsirkin]

On Mon, Jul 10, 2023 at 03:44:04PM +0530, Ani Sinha wrote:
> 
> 
> > On 10-Jul-2023, at 3:14 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > 
> > 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?
> 
> “this” is the following line I quoted above:
> 
> "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 think it applies for all devices in general (except VFs).

For all functions of devices with ARI support, yes. Does not apply to VFs.

> > 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
> >>>>> 
> >>> 
> >