Hi Daniel,
> Something is still not right with the logic here as this error report
is triggering on my machines. If I comment out this check, then I can
get data reported by libvirt
The VPD example you shared previously has multiple violations of the VPD format:
* Invalid field values ("N/A" in the read-only section, 0xFF in the
read-write section);
* The lack of the RW field at the end of the read-write section.
Previously, the VPD was discarded due to invalid values.
I thought honoring the RW requirement would still make sense and kept
the RW presence check.
I added it as a test case here (converted to hex):
https://listman.redhat.com/archives/libvir-list/2021-October/msg00871.html
The spec says the following (PCIe 4.0 "6.28.2.3 Read/Write Fields"):
"RW | Remaining Read/Write Area |
This descriptor is used to identify the unused portion of the
read/write space. The product
vendor initializes this parameter based on the size of the read/write
space or the space remaining
following the Vx VPD items. One or more of the Vx, Yx, and RW items
are required."
I can also confirm that by looking at the hexdump and looking for hex
values for R (0x52) and W (0x57):
hexdump -e '16/1 "0x%02x, " "\n"' vpd
I could ease it up and allow it to be missing as we do not care much
about it when reading so long as the resource
length is correct. However, if we were to allow Libvirt to write to
the read-write section in the future we would need to
know how much free space is there in the first place.
