Commit Graph

7 Commits

Author SHA1 Message Date
Ján Tomko
05cd957836 tests: pcivpdtest: check return value of virCreateAnonymousFile
Fixes: 59c1bc3a0e
Fixes: 43820e4b80
Fixes: 600f580d62
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Kristína Hanicová <khanicov@redhat.com>
2021-11-23 16:59:36 +01:00
Michal Privoznik
196e6faabd lib: Use G_N_ELEMENTS instead of sizeof()/sizeof()
For statically declared arrays one can use G_N_ELEMENTS() instead
of explicit sizeof(array) / sizeof(item). I've noticed couple of
places where the latter was used.

I am not fixing every occurrence because we have some places
which do not use glib (examples and NSS module).

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
2021-11-03 14:46:54 +01:00
Michal Privoznik
4f607caba0 virpcivpdtest: Declare variables at multiple lines
In testPCIVPDResourceCustomCompareIndex() there are two variables
declared at one line. They are both g_autoptr() decorated which
makes it worse, because coccinelle fails to parse that.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
2021-11-03 14:46:54 +01:00
Dmitrii Shcherbakov
935fbcf9da PCI VPD: Fix a wrong return code in a test case
The test case should return -1, not 0 in case a valid resource could
not be parsed successfully but the ret value is initialized to 0.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
2021-11-02 13:43:23 +00:00
Dmitrii Shcherbakov
600f580d62 PCI VPD: Skip fields with invalid values
While invalid values need to be ignored when presenting VPD data to the
user, it would be good to attempt to parse a valid portion of the VPD
instead of marking it invalid as a whole.

Based on a mailing list discussion, the set of accepted characters is
extended to the set of printable ASCII characters.

https://listman.redhat.com/archives/libvir-list/2021-October/msg01043.html

The particular example encountered on real hardware was multi-faceted:

* "N/A" strings present in read-only fields. This would not be a useful
  valid value for a field (especially if a unique serial number is
  expected), however, it was decided to delegate handling of those kinds
  of values to higher-level software;
* "4W/1W PCIeG2x4" - looks like some vendors use even more printable
  characters in the ASCII range than we currently allow. Since the
  PCI/PCIe VPD specs mention alphanumeric characters without specifying
  the full character set, it looks like this is ambiguous for vendors
  and they tend to use printable ASCII characters;
* 0xFF bytes present in VPD-W field values. Those bytes do not map to
  printable ASCII code points and were probably used by the vendor as
  placeholders. Ignoring the whole VPD because of that would be too
  strict.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
2021-11-02 13:43:23 +00:00
Dmitrii Shcherbakov
43820e4b80 PCI VPD: handle additional edge cases
* RV and RW fields must be at the last position in their respective
  section (per the conditions in the spec). Therefore, the parser now
  stops iterating over fields as soon as it encounters one of those
  fields and checks whether the end of the resource has been reached;
* The lack of the RW field is not treated as a parsing error since we
  can still extract valid data even though this is a PCI/PCIe VPD spec
  violation;
* Individual fields must have a valid length - the parser needs to check
  for invalid length values that violate boundary conditions of the
  resource.
* A zero-length field may be the last one in the resource, however, the
  boundary check is currently too strict to allow that.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
2021-11-02 13:43:23 +00:00
Dmitrii Shcherbakov
59c1bc3a0e Add a PCI/PCIe device VPD Parser
Add support for deserializing the binary PCI/PCIe VPD format and storing
results in memory.

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.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
2021-10-21 17:34:04 +01:00