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