On 05/25/2018 07:05 AM, Pino Toscano wrote:
On Thursday, 24 May 2018 14:24:33 CEST Xiao Feng Ren wrote:

From: Yi Min Zhao <zyimin@linux.ibm.com>

This patch introduces new XML parser/formatter functions. Uid is
16-bit and non-zero. Fid is 32-bit. They are added as two new
attributes of PCI address, and parsed/formatted along with PCI
address parser/formatter.

Signed-off-by: Yi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Stefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
---
 docs/schemas/basictypes.rng   | 28 ++++++++++++++++
 docs/schemas/domaincommon.rng |  1 +
 src/conf/device_conf.c        | 74 +++++++++++++++++++++++++++++++++++++++++++
 src/conf/domain_addr.c        |  3 ++
 src/conf/domain_conf.c        |  4 +++
 src/util/virpci.h             |  3 ++
 6 files changed, 113 insertions(+)

diff --git a/docs/schemas/basictypes.rng b/docs/schemas/basictypes.rng
index 1a18cd31b1..8050a3ebc4 100644
--- a/docs/schemas/basictypes.rng
+++ b/docs/schemas/basictypes.rng
@@ -111,6 +111,34 @@
       </attribute>
     </optional>
   </define>
+  <define name="zpciaddress">
+    <optional>
+      <attribute name="uid">
+        <choice>
+          <data type="string">
+            <param name="pattern">(0x)?[0-9a-fA-F]{1,4}</param>
+          </data>
+          <data type="unsignedInt">
+            <param name="minInclusive">1</param>
+            <param name="maxInclusive">65535</param>
+          </data>
+        </choice>
+      </attribute>

This seems to be the "uint16" type already.


+    </optional>
+    <optional>
+      <attribute name="fid">
+        <choice>
+          <data type="string">
+            <param name="pattern">(0x)?[0-9a-fA-F]{1,8}</param>
+          </data>
+          <data type="unsignedLong">
+            <param name="minInclusive">0</param>
+            <param name="maxInclusive">4294967295</param>
+          </data>
+        </choice>
+      </attribute>

This could be a new "uint32" type, changing the 0x prefix as
non-optional (otherwise the value "10" can be both valid as decimal
and hexadeciaml).

My personal opinion - if numbers without a leading 0x are consistently not interpreted as hexadecimal, then there is no ambiguity and no confusion. If there's a leading 0x, then it is hexadecimal. No leading 0x, it's decimal. Period.



@@ -57,6 +125,8 @@ void
 virDomainDeviceInfoClear(virDomainDeviceInfoPtr info)
 {
     VIR_FREE(info->alias);
+    if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+        VIR_FREE(info->addr.pci.zpci);

VIR_FREE should be safe to use on a NULL pointer, so just call it
directly without checking the type.

But this code isn't checking for a NULL pointer. It's checking to see which member of the union is being used - there may be a different address type that uses the same region of memory as something that isn't a pointer, and calling VIR_FREE would lead to dereferencing a bad pointer.



     memset(&info->addr, 0, sizeof(info->addr));
     info->type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE;
     VIR_FREE(info->romfile);
@@ -187,6 +257,7 @@ int virPCIDeviceAddressIsValid(virPCIDeviceAddressPtr addr,
                              "one of domain, bus, or slot must be > 0"));
         return 0;
     }
+
     return 1;
 }

Extra change.




--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list