On Wed, Oct 20, 2021 at 11:30:30AM +0300, Dmitrii Shcherbakov wrote:
> Add support for deserializing the binary PCI/PCIe VPD format and
> exposing VPD resources as XML elements in a new nested capability
> of PCI/PCIe devices called 'vpd'.
>
> The series contains the following incremental changes:
>
> * The PCI VPD parser module, in-memory resource representation
> and tests;
> * VPD-related helpers added to the virpci module;
> * VPD capability support: XML serialization/deserialization from/into
> VPD resource data structures;
> * Documentation.
>
> The VPD format is specified in "I.3. VPD Definitions" in PCI specs
> (2.2+) and "6.28.1 VPD Format" PCIe 4.0. As section 6.28 in PCIe 4.0
> notes, the PCI Local Bus and PCIe VPD formats are binary compatible
> and PCIe 4.0 merely started incorporating what was already present in
> PCI specs.
>
> Linux kernel exposes a binary blob in the VPD format via sysfs since
> v2.6.26 (commit 94e6108803469a37ee1e3c92dafdd1d59298602f) which requires
> a parser to interpret.
>
> There are usage scenarios where information such as the board serial
> number needs to be retrieved from PCI(e) VPD. Projects like Nova can
> utilize this information for cases which involve virtual interface
> plugging on SmartNIC DPUs but there may be other scenarios and types of
> information useful to retrieve from VPD. The fact that the format is
> binary requires proper parsing instead of substring searching hence the
> full parser is proposed. Likewise, checksum validation requires proper
> parsing as well.
>
> A usage example is present here:
> https://review.opendev.org/c/openstack/nova/+/808199
>
> The patch follows a prior discussion on the mailing list which has
> additional context about the use-case but a narrower proposal:
>
> https://listman.redhat.com/archives/libvir-list/2021-May/msg00873.html
> https://www.mail-archive.com/libvir-list@redhat.com/msg218165.html
>
> The new functionality is mostly contained in virpcivpd with a
> couple of new functions added to virpci. Additionally, the necessary XML
> serialization/deserialization and glue code is added to expose the VPD
> capability to external clients as XML.
>
> A new capability flag is added along with a new capability in order to
> allow for filtering of PCI devices with the VPD capability using virsh:
>
> virsh nodedev-list --cap vpd
> sudo virsh nodedev-dumpxml --device pci_dddd_bb_ss_f
>
> In this example having the root uid is required in order to access the
> vpd sysfs entry, therefore, the nodedev XML output will only contain
> the VPD capability if virsh is run as root.
>
> The capability is treated as dynamic due to the presence of read-write
> sections in the VPD format per PCI/PCIe specs (the idea being that
> read-write resource fields may potentially be altered by the DPU OS
> over time independently from the host OS).
>
> Unit tests cover the parser functionality (including many possible
> invalid cases), in-memory representation as well as XML serialization
> and deserialization.
>
> Manual functional testing was performed with 2 DPUs and several other
> NIC models which expose PCI(e) VPD. Testing have also been performed
> for devices that do not have VPD or those that expose a VPD capability
> but exhibit invalid behavior (I/O errors while reading a sysfs entry).
>
> v7 changes:
>
> * Fixed a number of memleaks in virpcivpd.c, virpcivpdtest.c,
> node_device_conf.c (see the test results in a paste below);
> * Moved some preprocessor definitions and virPCIVPDResourceFieldValueFormat
> to virpcivpdpriv.h (not the .c file since those are used in unit tests);
> * virPCIVPDResourceUpdateKeyword now prints a warning and returns true for
> unexpected keywords, whereas virPCIVPDParseVPDLargeResourceFields fails
> on errors returned from virPCIVPDResourceUpdateKeyword;
> * Updates to static fields now free the memory allocated to old values.
Since the issues i pointed out are minimal, I've just made them
myself and will push this once I see gitlab CI passing for it.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|