linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH RESEND] lspci: Decode VF 10-Bit Tag Requester
@ 2021-03-03 11:14 Dongdong Liu
  2021-03-07  1:45 ` Krzysztof Wilczyński
  0 siblings, 1 reply; 4+ messages in thread
From: Dongdong Liu @ 2021-03-03 11:14 UTC (permalink / raw)
  To: mj, helgaas, linux-pci

Decode VF 10-Bit Tag Requester Supported and Enable bit
in SR-IOV Capabilities Register.

Sample output:
  IOVCap: Migration-, 10BitTagReq+, Interrupt Message Number: 000
  IOVCtl: Enable+ Migration- Interrupt- MSE+ ARIHierarchy- 10BitTagReq+

Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
---
 lib/header.h | 2 ++
 ls-ecaps.c   | 8 ++++----
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/lib/header.h b/lib/header.h
index 170e5c1..bff49c2 100644
--- a/lib/header.h
+++ b/lib/header.h
@@ -1126,6 +1126,7 @@
 /* Single Root I/O Virtualization */
 #define PCI_IOV_CAP		0x04	/* SR-IOV Capability Register */
 #define  PCI_IOV_CAP_VFM	0x00000001 /* VF Migration Capable */
+#define  PCI_IOV_CAP_VF_10BIT_TAG_REQ 0x00000004 /* VF 10-Bit Tag Requester Supported */
 #define  PCI_IOV_CAP_IMN(x)	((x) >> 21) /* VF Migration Interrupt Message Number */
 #define PCI_IOV_CTRL		0x08	/* SR-IOV Control Register */
 #define  PCI_IOV_CTRL_VFE	0x0001	/* VF Enable */
@@ -1133,6 +1134,7 @@
 #define  PCI_IOV_CTRL_VFMIE	0x0004	/* VF Migration Interrupt Enable */
 #define  PCI_IOV_CTRL_MSE	0x0008	/* VF MSE */
 #define  PCI_IOV_CTRL_ARI	0x0010	/* ARI Capable Hierarchy */
+#define  PCI_IOV_CTRL_VF_10BIT_TAG_REQ_EN 0x0020 /* VF 10-Bit Tag Requester Enable */
 #define PCI_IOV_STATUS		0x0a	/* SR-IOV Status Register */
 #define  PCI_IOV_STATUS_MS	0x0001	/* VF Migration Status */
 #define PCI_IOV_INITIALVF	0x0c	/* Number of VFs that are initially associated */
diff --git a/ls-ecaps.c b/ls-ecaps.c
index 99c55ff..9b50aec 100644
--- a/ls-ecaps.c
+++ b/ls-ecaps.c
@@ -369,13 +369,13 @@ cap_sriov(struct device *d, int where)
     return;
 
   l = get_conf_long(d, where + PCI_IOV_CAP);
-  printf("\t\tIOVCap:\tMigration%c, Interrupt Message Number: %03x\n",
-	FLAG(l, PCI_IOV_CAP_VFM), PCI_IOV_CAP_IMN(l));
+  printf("\t\tIOVCap:\tMigration%c, 10BitTagReq%c, Interrupt Message Number: %03x\n",
+	FLAG(l, PCI_IOV_CAP_VFM), FLAG(l, PCI_IOV_CAP_VF_10BIT_TAG_REQ), PCI_IOV_CAP_IMN(l));
   w = get_conf_word(d, where + PCI_IOV_CTRL);
-  printf("\t\tIOVCtl:\tEnable%c Migration%c Interrupt%c MSE%c ARIHierarchy%c\n",
+  printf("\t\tIOVCtl:\tEnable%c Migration%c Interrupt%c MSE%c ARIHierarchy%c 10BitTagReq%c\n",
 	FLAG(w, PCI_IOV_CTRL_VFE), FLAG(w, PCI_IOV_CTRL_VFME),
 	FLAG(w, PCI_IOV_CTRL_VFMIE), FLAG(w, PCI_IOV_CTRL_MSE),
-	FLAG(w, PCI_IOV_CTRL_ARI));
+	FLAG(w, PCI_IOV_CTRL_ARI), FLAG(w, PCI_IOV_CTRL_VF_10BIT_TAG_REQ_EN));
   w = get_conf_word(d, where + PCI_IOV_STATUS);
   printf("\t\tIOVSta:\tMigration%c\n", FLAG(w, PCI_IOV_STATUS_MS));
   w = get_conf_word(d, where + PCI_IOV_INITIALVF);
-- 
1.9.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH RESEND] lspci: Decode VF 10-Bit Tag Requester
  2021-03-03 11:14 [PATCH RESEND] lspci: Decode VF 10-Bit Tag Requester Dongdong Liu
@ 2021-03-07  1:45 ` Krzysztof Wilczyński
  2021-03-08 14:47   ` Dongdong Liu
  0 siblings, 1 reply; 4+ messages in thread
From: Krzysztof Wilczyński @ 2021-03-07  1:45 UTC (permalink / raw)
  To: Dongdong Liu; +Cc: mj, helgaas, linux-pci

Hi,

[+cc Bjorn who was workingo on making commas usage more consistent]

Thank you for sending the patch over.

> Decode VF 10-Bit Tag Requester Supported and Enable bit
> in SR-IOV Capabilities Register.
> 
> Sample output:
>   IOVCap: Migration-, 10BitTagReq+, Interrupt Message Number: 000
>   IOVCtl: Enable+ Migration- Interrupt- MSE+ ARIHierarchy- 10BitTagReq+
[...]

Would you be able to move the "10BitTagReq" in the "IOVCtl" after the
"Migration" so that its placement is consistent with the "IOVCap"?  This
would be also along the lines of how the same files is already used in
the ls-caps.c file.

Bjorn was also working on making a lot of the commas usage throughout to
follow the best practice, thus I believe that the commas there would not
be needed.  Having said that, it might be better to follow the current
style present there at the moment.

See 018f413 ("lspci: Use commas more consistently") for more details on
Bjorn's work to normalise the usage of commas.

Additionally, with the new fields, would you also have to update some of
the tests files?  For example:

  Index File                Line Content
      0 tests/cap-dvsec-cxl   81 Capabilities: [b80 v1] Single Root I/O Virtualization (SR-IOV)
      1 tests/cap-dvsec-cxl   82 IOVCap: Migration-, Interrupt Message Number: 000
      2 tests/cap-dvsec-cxl   83 IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy-
      3 tests/cap-dvsec-cxl   84 IOVSta: Migration-
      4 tests/cap-pcie-2      50 Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
      5 tests/cap-pcie-2      51 IOVCap:  Migration-, Interrupt Message Number: 000
      6 tests/cap-pcie-2      52 IOVCtl:  Enable+ Migration- Interrupt- MSE+ ARIHierarchy-
      7 tests/cap-pcie-2      53 IOVSta:  Migration-
      8 tests/cap-ea-1        59 Capabilities: [180 v1] Single Root I/O Virtualization (SR-IOV)
      9 tests/cap-ea-1        60 IOVCap:  Migration-, Interrupt Message Number: 000
     10 tests/cap-ea-1        61 IOVCtl:  Enable+ Migration- Interrupt- MSE+ ARIHierarchy+
     11 tests/cap-ea-1        62 IOVSta:  Migration-

Otheriwse, it looks good!  Thank you!

Krzysztof

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RESEND] lspci: Decode VF 10-Bit Tag Requester
  2021-03-07  1:45 ` Krzysztof Wilczyński
@ 2021-03-08 14:47   ` Dongdong Liu
  2021-03-08 15:09     ` Krzysztof Wilczyński
  0 siblings, 1 reply; 4+ messages in thread
From: Dongdong Liu @ 2021-03-08 14:47 UTC (permalink / raw)
  To: Krzysztof Wilczyński; +Cc: mj, helgaas, linux-pci


Hi Krzysztof

Many thanks for your review.

On 2021/3/7 9:45, Krzysztof Wilczyński wrote:
> Hi,
>
> [+cc Bjorn who was workingo on making commas usage more consistent]
>
> Thank you for sending the patch over.
>
>> Decode VF 10-Bit Tag Requester Supported and Enable bit
>> in SR-IOV Capabilities Register.
>>
>> Sample output:
>>   IOVCap: Migration-, 10BitTagReq+, Interrupt Message Number: 000
>>   IOVCtl: Enable+ Migration- Interrupt- MSE+ ARIHierarchy- 10BitTagReq+
> [...]
>
> Would you be able to move the "10BitTagReq" in the "IOVCtl" after the
> "Migration" so that its placement is consistent with the "IOVCap"?  This
> would be also along the lines of how the same files is already used in
> the ls-caps.c file.

To be honest, I am not sure this is suitable.
PCIe 5.0r1.0 spec section 9.3.3.2 SR-IOV Capabilities Register
VF 10-Bit Tag Requester Supported defined in BIT[2].

9.3.3.3 SR-IOV Control Register (Offset 08h)
VF 10-Bit Tag Requester Enable defined in BIT[5] and this is after the 
BIT[4] ARI Capable Hierarchy.

Howerver if we need to keep consistent with the "IOVCap". I can
move the "10BitTagReq" in the "IOVCtl" after the "Migration".

>
> Bjorn was also working on making a lot of the commas usage throughout to
> follow the best practice, thus I believe that the commas there would not
> be needed.  Having said that, it might be better to follow the current
> style present there at the moment.
>
> See 018f413 ("lspci: Use commas more consistently") for more details on
> Bjorn's work to normalise the usage of commas.

Good suggestion, will fix.
>
> Additionally, with the new fields, would you also have to update some of
> the tests files?  For example:
>
>   Index File                Line Content
>       0 tests/cap-dvsec-cxl   81 Capabilities: [b80 v1] Single Root I/O Virtualization (SR-IOV)
>       1 tests/cap-dvsec-cxl   82 IOVCap: Migration-, Interrupt Message Number: 000
>       2 tests/cap-dvsec-cxl   83 IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy-
>       3 tests/cap-dvsec-cxl   84 IOVSta: Migration-
>       4 tests/cap-pcie-2      50 Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
>       5 tests/cap-pcie-2      51 IOVCap:  Migration-, Interrupt Message Number: 000
>       6 tests/cap-pcie-2      52 IOVCtl:  Enable+ Migration- Interrupt- MSE+ ARIHierarchy-
>       7 tests/cap-pcie-2      53 IOVSta:  Migration-
>       8 tests/cap-ea-1        59 Capabilities: [180 v1] Single Root I/O Virtualization (SR-IOV)
>       9 tests/cap-ea-1        60 IOVCap:  Migration-, Interrupt Message Number: 000
>      10 tests/cap-ea-1        61 IOVCtl:  Enable+ Migration- Interrupt- MSE+ ARIHierarchy+
>      11 tests/cap-ea-1        62 IOVSta:  Migration-
>
OK, will do.

Thanks,
Dongdong
> Otheriwse, it looks good!  Thank you!
>
> Krzysztof
> .
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RESEND] lspci: Decode VF 10-Bit Tag Requester
  2021-03-08 14:47   ` Dongdong Liu
@ 2021-03-08 15:09     ` Krzysztof Wilczyński
  0 siblings, 0 replies; 4+ messages in thread
From: Krzysztof Wilczyński @ 2021-03-08 15:09 UTC (permalink / raw)
  To: Dongdong Liu; +Cc: mj, helgaas, linux-pci

Hi,

[...]
> > Would you be able to move the "10BitTagReq" in the "IOVCtl" after the
> > "Migration" so that its placement is consistent with the "IOVCap"?  This
> > would be also along the lines of how the same files is already used in
> > the ls-caps.c file.
> 
> To be honest, I am not sure this is suitable.
> PCIe 5.0r1.0 spec section 9.3.3.2 SR-IOV Capabilities Register
> VF 10-Bit Tag Requester Supported defined in BIT[2].
> 
> 9.3.3.3 SR-IOV Control Register (Offset 08h)
> VF 10-Bit Tag Requester Enable defined in BIT[5] and this is after the
> BIT[4] ARI Capable Hierarchy.

That makes sense.  I have to admit, I didn't think of keeping the order
following which bits are set.  That's a nice idea.  I see that "DevCap2"
and "DevCtl2" also follow this approach.
 
> Howerver if we need to keep consistent with the "IOVCap". I can
> move the "10BitTagReq" in the "IOVCtl" after the "Migration".

No need.  You are right.  It's better to keep it as you originally
intended, make a lot more sense.

Also, thank you for the explanation!  Much appreciated.

[...]
> > Bjorn was also working on making a lot of the commas usage throughout to
> > follow the best practice, thus I believe that the commas there would not
> > be needed.  Having said that, it might be better to follow the current
> > style present there at the moment.
> > 
> > See 018f413 ("lspci: Use commas more consistently") for more details on
> > Bjorn's work to normalise the usage of commas.
> 
> Good suggestion, will fix.

Thank you!

> > Additionally, with the new fields, would you also have to update some of
> > the tests files?  For example:
> > 
> >   Index File                Line Content
> >       0 tests/cap-dvsec-cxl   81 Capabilities: [b80 v1] Single Root I/O Virtualization (SR-IOV)
> >       1 tests/cap-dvsec-cxl   82 IOVCap: Migration-, Interrupt Message Number: 000
> >       2 tests/cap-dvsec-cxl   83 IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy-
> >       3 tests/cap-dvsec-cxl   84 IOVSta: Migration-
> >       4 tests/cap-pcie-2      50 Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
> >       5 tests/cap-pcie-2      51 IOVCap:  Migration-, Interrupt Message Number: 000
> >       6 tests/cap-pcie-2      52 IOVCtl:  Enable+ Migration- Interrupt- MSE+ ARIHierarchy-
> >       7 tests/cap-pcie-2      53 IOVSta:  Migration-
> >       8 tests/cap-ea-1        59 Capabilities: [180 v1] Single Root I/O Virtualization (SR-IOV)
> >       9 tests/cap-ea-1        60 IOVCap:  Migration-, Interrupt Message Number: 000
> >      10 tests/cap-ea-1        61 IOVCtl:  Enable+ Migration- Interrupt- MSE+ ARIHierarchy+
> >      11 tests/cap-ea-1        62 IOVSta:  Migration-
> > 
> OK, will do.

Superb!  Thank you!

Krzysztof

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-03-08 15:10 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-03 11:14 [PATCH RESEND] lspci: Decode VF 10-Bit Tag Requester Dongdong Liu
2021-03-07  1:45 ` Krzysztof Wilczyński
2021-03-08 14:47   ` Dongdong Liu
2021-03-08 15:09     ` Krzysztof Wilczyński

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).