[libvirt] [PATCH v2 RESEND 03/12] conf: Introduce a new PCI address extension flag

Yi Min Zhao posted 12 patches 7 years, 7 months ago
There is a newer version of this series
[libvirt] [PATCH v2 RESEND 03/12] conf: Introduce a new PCI address extension flag
Posted by Yi Min Zhao 7 years, 7 months ago
This patch introduces a new attribute PCI address extension flag
to deal with the extension PCI attributes such as 'uid' and 'fid'
on the S390 platform.

Signed-off-by: Yi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
---
 src/conf/device_conf.h         |   1 +
 src/conf/domain_addr.h         |   5 ++
 src/qemu/qemu_domain_address.c | 135 ++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 139 insertions(+), 2 deletions(-)

diff --git a/src/conf/device_conf.h b/src/conf/device_conf.h
index a31ce9c376..6f926dff1d 100644
--- a/src/conf/device_conf.h
+++ b/src/conf/device_conf.h
@@ -164,6 +164,7 @@ struct _virDomainDeviceInfo {
      * assignment, never saved and never reported.
      */
     int pciConnectFlags; /* enum virDomainPCIConnectFlags */
+    int pciAddressExtFlags; /* enum virDomainPCIAddressExtensionFlags */
     char *loadparm;
 
     /* PCI devices will only be automatically placed on a PCI bus
diff --git a/src/conf/domain_addr.h b/src/conf/domain_addr.h
index 5ad9d8ef3d..5219d2f208 100644
--- a/src/conf/domain_addr.h
+++ b/src/conf/domain_addr.h
@@ -29,6 +29,11 @@
 # define VIR_PCI_ADDRESS_SLOT_LAST 31
 # define VIR_PCI_ADDRESS_FUNCTION_LAST 7
 
+typedef enum {
+    VIR_PCI_ADDRESS_EXTENSION_NONE = 0, /* no extension */
+    VIR_PCI_ADDRESS_EXTENSION_ZPCI = 1 << 0, /* zpci support */
+} virDomainPCIAddressExtensionFlags;
+
 typedef enum {
    VIR_PCI_CONNECT_HOTPLUGGABLE = 1 << 0, /* is hotplug needed/supported */
 
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 6ea80616af..c634d216f5 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -480,6 +480,58 @@ qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr def,
 }
 
 
+static bool
+qemuDomainDeviceSupportZPCI(virDomainDeviceDefPtr device)
+{
+    switch ((virDomainDeviceType) device->type) {
+    case VIR_DOMAIN_DEVICE_CHR:
+        return false;
+
+    case VIR_DOMAIN_DEVICE_CONTROLLER:
+    case VIR_DOMAIN_DEVICE_NONE:
+    case VIR_DOMAIN_DEVICE_DISK:
+    case VIR_DOMAIN_DEVICE_LEASE:
+    case VIR_DOMAIN_DEVICE_FS:
+    case VIR_DOMAIN_DEVICE_NET:
+    case VIR_DOMAIN_DEVICE_INPUT:
+    case VIR_DOMAIN_DEVICE_SOUND:
+    case VIR_DOMAIN_DEVICE_VIDEO:
+    case VIR_DOMAIN_DEVICE_HOSTDEV:
+    case VIR_DOMAIN_DEVICE_WATCHDOG:
+    case VIR_DOMAIN_DEVICE_GRAPHICS:
+    case VIR_DOMAIN_DEVICE_HUB:
+    case VIR_DOMAIN_DEVICE_REDIRDEV:
+    case VIR_DOMAIN_DEVICE_SMARTCARD:
+    case VIR_DOMAIN_DEVICE_MEMBALLOON:
+    case VIR_DOMAIN_DEVICE_NVRAM:
+    case VIR_DOMAIN_DEVICE_RNG:
+    case VIR_DOMAIN_DEVICE_SHMEM:
+    case VIR_DOMAIN_DEVICE_TPM:
+    case VIR_DOMAIN_DEVICE_PANIC:
+    case VIR_DOMAIN_DEVICE_MEMORY:
+    case VIR_DOMAIN_DEVICE_IOMMU:
+    case VIR_DOMAIN_DEVICE_VSOCK:
+    case VIR_DOMAIN_DEVICE_LAST:
+        break;
+    }
+    return true;
+}
+
+
+static virDomainPCIAddressExtensionFlags
+qemuDomainDeviceCalculatePCIAddressExtensionFlags(virQEMUCapsPtr qemuCaps,
+                                                  virDomainDeviceDefPtr dev)
+{
+    virDomainPCIAddressExtensionFlags extFlags = 0;
+
+    if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_ZPCI) &&
+        qemuDomainDeviceSupportZPCI(dev))
+        extFlags |= VIR_PCI_ADDRESS_EXTENSION_ZPCI;
+
+    return extFlags;
+}
+
+
 /**
  * qemuDomainDeviceCalculatePCIConnectFlags:
  *
@@ -961,6 +1013,55 @@ qemuDomainFillAllPCIConnectFlags(virDomainDefPtr def,
 }
 
 
+/**
+ * qemuDomainFillDevicePCIExtensionFlagsIter:
+ *
+ * @def: the entire DomainDef
+ * @dev: The device to be checked
+ * @info: virDomainDeviceInfo within the device
+ * @opaque: qemu capabilities
+ *
+ * Sets the pciAddressExtFlags for a single device's info. Has properly
+ * formatted arguments to be called by virDomainDeviceInfoIterate().
+ *
+ * Always returns 0 - there is no failure.
+ */
+static int
+qemuDomainFillDevicePCIExtensionFlagsIter(virDomainDefPtr def ATTRIBUTE_UNUSED,
+                                          virDomainDeviceDefPtr dev,
+                                          virDomainDeviceInfoPtr info,
+                                          void *opaque)
+{
+    virQEMUCapsPtr qemuCaps = opaque;
+
+    info->pciAddressExtFlags
+        = qemuDomainDeviceCalculatePCIAddressExtensionFlags(qemuCaps, dev);
+    return 0;
+}
+
+
+/**
+ * qemuDomainFillAllPCIExtensionFlags:
+ *
+ * @def: the entire DomainDef
+ * @qemuCaps: as you'd expect
+ *
+ * Set the info->pciAddressExtFlags for all devices in the domain.
+ *
+ * Returns 0 on success or -1 on failure (the only possibility of
+ * failure would be some internal problem with
+ * virDomainDeviceInfoIterate())
+ */
+static int
+qemuDomainFillAllPCIExtensionFlags(virDomainDefPtr def,
+                                   virQEMUCapsPtr qemuCaps)
+{
+    return virDomainDeviceInfoIterate(def,
+                                      qemuDomainFillDevicePCIExtensionFlagsIter,
+                                      qemuCaps);
+}
+
+
 /**
  * qemuDomainFindUnusedIsolationGroupIter:
  * @def: domain definition
@@ -1235,6 +1336,29 @@ qemuDomainFillDevicePCIConnectFlags(virDomainDefPtr def,
 }
 
 
+/**
+ * qemuDomainFillDevicePCIExtensionFlags:
+ *
+ * @dev: The device to be checked
+ * @qemuCaps: as you'd expect
+ *
+ * Set the info->pciAddressExtFlags for a single device.
+ *
+ * No return value.
+ */
+static void
+qemuDomainFillDevicePCIExtensionFlags(virDomainDeviceDefPtr dev,
+                                      virQEMUCapsPtr qemuCaps)
+{
+    virDomainDeviceInfoPtr info = virDomainDeviceGetInfo(dev);
+
+    if (info) {
+        info->pciAddressExtFlags
+            = qemuDomainDeviceCalculatePCIAddressExtensionFlags(qemuCaps, dev);
+    }
+}
+
+
 static int
 qemuDomainPCIAddressReserveNextAddr(virDomainPCIAddressSetPtr addrs,
                                     virDomainDeviceInfoPtr dev)
@@ -2363,6 +2487,9 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def,
     if (qemuDomainFillAllPCIConnectFlags(def, qemuCaps, driver) < 0)
         goto cleanup;
 
+    if (qemuDomainFillAllPCIExtensionFlags(def, qemuCaps) < 0)
+        goto cleanup;
+
     if (qemuDomainSetupIsolationGroups(def) < 0)
         goto cleanup;
 
@@ -2398,7 +2525,8 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def,
              */
             virDomainDeviceInfo info = {
                 .pciConnectFlags = (VIR_PCI_CONNECT_HOTPLUGGABLE |
-                                    VIR_PCI_CONNECT_TYPE_PCI_DEVICE)
+                                    VIR_PCI_CONNECT_TYPE_PCI_DEVICE),
+                .pciAddressExtFlags = VIR_PCI_ADDRESS_EXTENSION_NONE
             };
             bool buses_reserved = true;
 
@@ -2435,7 +2563,8 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def,
             qemuDomainHasPCIeRoot(def)) {
             virDomainDeviceInfo info = {
                 .pciConnectFlags = (VIR_PCI_CONNECT_HOTPLUGGABLE |
-                                    VIR_PCI_CONNECT_TYPE_PCIE_DEVICE)
+                                    VIR_PCI_CONNECT_TYPE_PCIE_DEVICE),
+                .pciAddressExtFlags = VIR_PCI_ADDRESS_EXTENSION_NONE
             };
 
             /* if there isn't an empty pcie-root-port, this will
@@ -2952,6 +3081,8 @@ qemuDomainEnsurePCIAddress(virDomainObjPtr obj,
 
     qemuDomainFillDevicePCIConnectFlags(obj->def, dev, priv->qemuCaps, driver);
 
+    qemuDomainFillDevicePCIExtensionFlags(dev, priv->qemuCaps);
+
     return virDomainPCIAddressEnsureAddr(priv->pciaddrs, info,
                                          info->pciConnectFlags);
 }
-- 
Yi Min

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 RESEND 03/12] conf: Introduce a new PCI address extension flag
Posted by Andrea Bolognani 7 years, 6 months ago
On Tue, 2018-07-10 at 16:02 +0800, Yi Min Zhao wrote:
[...]
> +static bool
> +qemuDomainDeviceSupportZPCI(virDomainDeviceDefPtr device)
> +{
> +    switch ((virDomainDeviceType) device->type) {
> +    case VIR_DOMAIN_DEVICE_CHR:
> +        return false;
> +
> +    case VIR_DOMAIN_DEVICE_CONTROLLER:
> +    case VIR_DOMAIN_DEVICE_NONE:
> +    case VIR_DOMAIN_DEVICE_DISK:
> +    case VIR_DOMAIN_DEVICE_LEASE:
> +    case VIR_DOMAIN_DEVICE_FS:
> +    case VIR_DOMAIN_DEVICE_NET:
> +    case VIR_DOMAIN_DEVICE_INPUT:
> +    case VIR_DOMAIN_DEVICE_SOUND:
> +    case VIR_DOMAIN_DEVICE_VIDEO:
> +    case VIR_DOMAIN_DEVICE_HOSTDEV:
> +    case VIR_DOMAIN_DEVICE_WATCHDOG:
> +    case VIR_DOMAIN_DEVICE_GRAPHICS:
> +    case VIR_DOMAIN_DEVICE_HUB:
> +    case VIR_DOMAIN_DEVICE_REDIRDEV:
> +    case VIR_DOMAIN_DEVICE_SMARTCARD:
> +    case VIR_DOMAIN_DEVICE_MEMBALLOON:
> +    case VIR_DOMAIN_DEVICE_NVRAM:
> +    case VIR_DOMAIN_DEVICE_RNG:
> +    case VIR_DOMAIN_DEVICE_SHMEM:
> +    case VIR_DOMAIN_DEVICE_TPM:
> +    case VIR_DOMAIN_DEVICE_PANIC:
> +    case VIR_DOMAIN_DEVICE_MEMORY:
> +    case VIR_DOMAIN_DEVICE_IOMMU:
> +    case VIR_DOMAIN_DEVICE_VSOCK:
> +    case VIR_DOMAIN_DEVICE_LAST:
> +        break;

Did you validate that all of the above can be used with zPCI?

Either way, at least _NONE and _LAST should definitely result in
an error being reported, as well as the default case which should
be included; use virReportEnumRangeError() for convenience.

[...]
> +static virDomainPCIAddressExtensionFlags
> +qemuDomainDeviceCalculatePCIAddressExtensionFlags(virQEMUCapsPtr qemuCaps,
> +                                                  virDomainDeviceDefPtr dev)
> +{
> +    virDomainPCIAddressExtensionFlags extFlags = 0;
> +
> +    if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_ZPCI) &&
> +        qemuDomainDeviceSupportZPCI(dev))
> +        extFlags |= VIR_PCI_ADDRESS_EXTENSION_ZPCI;

The libvirt code style guidelines[1] state that this should be
formatted as

  if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_ZPCI) &&
      qemuDomainDeviceSupportZPCI(dev)) {
      extFlags |= VIR_PCI_ADDRESS_EXTENSION_ZPCI;
  }

[1] https://libvirt.org/hacking.html
-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 RESEND 03/12] conf: Introduce a new PCI address extension flag
Posted by Yi Min Zhao 7 years, 6 months ago

在 2018/7/24 下午9:54, Andrea Bolognani 写道:
> On Tue, 2018-07-10 at 16:02 +0800, Yi Min Zhao wrote:
> [...]
>> +static bool
>> +qemuDomainDeviceSupportZPCI(virDomainDeviceDefPtr device)
>> +{
>> +    switch ((virDomainDeviceType) device->type) {
>> +    case VIR_DOMAIN_DEVICE_CHR:
>> +        return false;
>> +
>> +    case VIR_DOMAIN_DEVICE_CONTROLLER:
>> +    case VIR_DOMAIN_DEVICE_NONE:
>> +    case VIR_DOMAIN_DEVICE_DISK:
>> +    case VIR_DOMAIN_DEVICE_LEASE:
>> +    case VIR_DOMAIN_DEVICE_FS:
>> +    case VIR_DOMAIN_DEVICE_NET:
>> +    case VIR_DOMAIN_DEVICE_INPUT:
>> +    case VIR_DOMAIN_DEVICE_SOUND:
>> +    case VIR_DOMAIN_DEVICE_VIDEO:
>> +    case VIR_DOMAIN_DEVICE_HOSTDEV:
>> +    case VIR_DOMAIN_DEVICE_WATCHDOG:
>> +    case VIR_DOMAIN_DEVICE_GRAPHICS:
>> +    case VIR_DOMAIN_DEVICE_HUB:
>> +    case VIR_DOMAIN_DEVICE_REDIRDEV:
>> +    case VIR_DOMAIN_DEVICE_SMARTCARD:
>> +    case VIR_DOMAIN_DEVICE_MEMBALLOON:
>> +    case VIR_DOMAIN_DEVICE_NVRAM:
>> +    case VIR_DOMAIN_DEVICE_RNG:
>> +    case VIR_DOMAIN_DEVICE_SHMEM:
>> +    case VIR_DOMAIN_DEVICE_TPM:
>> +    case VIR_DOMAIN_DEVICE_PANIC:
>> +    case VIR_DOMAIN_DEVICE_MEMORY:
>> +    case VIR_DOMAIN_DEVICE_IOMMU:
>> +    case VIR_DOMAIN_DEVICE_VSOCK:
>> +    case VIR_DOMAIN_DEVICE_LAST:
>> +        break;
> Did you validate that all of the above can be used with zPCI?
Yes, I did. But how far can zPCI be used is a question. I make sure that 
if their address
type can be PCI type zPCI address could be expanded. But we don't 
guarantee they can
be really used in qemu. Like RNG device can't be used because it doesn't 
support MSIx
which is required on S390.
>
> Either way, at least _NONE and _LAST should definitely result in
> an error being reported, as well as the default case which should
> be included; use virReportEnumRangeError() for convenience.
Will update this as your comment.
>
> [...]
>> +static virDomainPCIAddressExtensionFlags
>> +qemuDomainDeviceCalculatePCIAddressExtensionFlags(virQEMUCapsPtr qemuCaps,
>> +                                                  virDomainDeviceDefPtr dev)
>> +{
>> +    virDomainPCIAddressExtensionFlags extFlags = 0;
>> +
>> +    if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_ZPCI) &&
>> +        qemuDomainDeviceSupportZPCI(dev))
>> +        extFlags |= VIR_PCI_ADDRESS_EXTENSION_ZPCI;
> The libvirt code style guidelines[1] state that this should be
> formatted as
>
>    if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_ZPCI) &&
>        qemuDomainDeviceSupportZPCI(dev)) {
>        extFlags |= VIR_PCI_ADDRESS_EXTENSION_ZPCI;
>    }
>
> [1] https://libvirt.org/hacking.html
I see a lot of code in libvirt use this style. Is it new guideline?

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 RESEND 03/12] conf: Introduce a new PCI address extension flag
Posted by Andrea Bolognani 7 years, 6 months ago
On Wed, 2018-07-25 at 16:58 +0800, Yi Min Zhao wrote:
[...]
> > > +    case VIR_DOMAIN_DEVICE_CONTROLLER:
> > > +    case VIR_DOMAIN_DEVICE_DISK:
> > > +    case VIR_DOMAIN_DEVICE_LEASE:
> > > +    case VIR_DOMAIN_DEVICE_FS:
> > > +    case VIR_DOMAIN_DEVICE_NET:
> > > +    case VIR_DOMAIN_DEVICE_INPUT:
> > > +    case VIR_DOMAIN_DEVICE_SOUND:
> > > +    case VIR_DOMAIN_DEVICE_VIDEO:
> > > +    case VIR_DOMAIN_DEVICE_HOSTDEV:
> > > +    case VIR_DOMAIN_DEVICE_WATCHDOG:
> > > +    case VIR_DOMAIN_DEVICE_GRAPHICS:
> > > +    case VIR_DOMAIN_DEVICE_HUB:
> > > +    case VIR_DOMAIN_DEVICE_REDIRDEV:
> > > +    case VIR_DOMAIN_DEVICE_SMARTCARD:
> > > +    case VIR_DOMAIN_DEVICE_MEMBALLOON:
> > > +    case VIR_DOMAIN_DEVICE_NVRAM:
> > > +    case VIR_DOMAIN_DEVICE_RNG:
> > > +    case VIR_DOMAIN_DEVICE_SHMEM:
> > > +    case VIR_DOMAIN_DEVICE_TPM:
> > > +    case VIR_DOMAIN_DEVICE_PANIC:
> > > +    case VIR_DOMAIN_DEVICE_MEMORY:
> > > +    case VIR_DOMAIN_DEVICE_IOMMU:
> > > +    case VIR_DOMAIN_DEVICE_VSOCK:
> > 
> > Did you validate that all of the above can be used with zPCI?
> 
> Yes, I did. But how far can zPCI be used is a question. I make sure that 
> if their address
> type can be PCI type zPCI address could be expanded. But we don't 
> guarantee they can
> be really used in qemu. Like RNG device can't be used because it doesn't 
> support MSIx
> which is required on S390.

If that's the case, I'm not sure the current solution is what we
want: if someone creates a guest and includes a RNG device in the
configuration, they probably expect it to, well, work. IIUC, with
the current implementation they would get a non-working RNG device
instead, which certainly feels suboptimal.

> > [...]
> > > +static virDomainPCIAddressExtensionFlags
> > > +qemuDomainDeviceCalculatePCIAddressExtensionFlags(virQEMUCapsPtr qemuCaps,
> > > +                                                  virDomainDeviceDefPtr dev)
> > > +{
> > > +    virDomainPCIAddressExtensionFlags extFlags = 0;
> > > +
> > > +    if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_ZPCI) &&
> > > +        qemuDomainDeviceSupportZPCI(dev))
> > > +        extFlags |= VIR_PCI_ADDRESS_EXTENSION_ZPCI;
> > 
> > The libvirt code style guidelines[1] state that this should be
> > formatted as
> > 
> >    if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_ZPCI) &&
> >        qemuDomainDeviceSupportZPCI(dev)) {
> >        extFlags |= VIR_PCI_ADDRESS_EXTENSION_ZPCI;
> >    }
> > 
> > [1] https://libvirt.org/hacking.html
> 
> I see a lot of code in libvirt use this style. Is it new guideline?

It's certainly been around for the past 3+ years. There's a lot of
code in libvirt that's *way* older than that, though :)

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 RESEND 03/12] conf: Introduce a new PCI address extension flag
Posted by Yi Min Zhao 7 years, 6 months ago

在 2018/7/25 下午9:31, Andrea Bolognani 写道:
> On Wed, 2018-07-25 at 16:58 +0800, Yi Min Zhao wrote:
> [...]
>>>> +    case VIR_DOMAIN_DEVICE_CONTROLLER:
>>>> +    case VIR_DOMAIN_DEVICE_DISK:
>>>> +    case VIR_DOMAIN_DEVICE_LEASE:
>>>> +    case VIR_DOMAIN_DEVICE_FS:
>>>> +    case VIR_DOMAIN_DEVICE_NET:
>>>> +    case VIR_DOMAIN_DEVICE_INPUT:
>>>> +    case VIR_DOMAIN_DEVICE_SOUND:
>>>> +    case VIR_DOMAIN_DEVICE_VIDEO:
>>>> +    case VIR_DOMAIN_DEVICE_HOSTDEV:
>>>> +    case VIR_DOMAIN_DEVICE_WATCHDOG:
>>>> +    case VIR_DOMAIN_DEVICE_GRAPHICS:
>>>> +    case VIR_DOMAIN_DEVICE_HUB:
>>>> +    case VIR_DOMAIN_DEVICE_REDIRDEV:
>>>> +    case VIR_DOMAIN_DEVICE_SMARTCARD:
>>>> +    case VIR_DOMAIN_DEVICE_MEMBALLOON:
>>>> +    case VIR_DOMAIN_DEVICE_NVRAM:
>>>> +    case VIR_DOMAIN_DEVICE_RNG:
>>>> +    case VIR_DOMAIN_DEVICE_SHMEM:
>>>> +    case VIR_DOMAIN_DEVICE_TPM:
>>>> +    case VIR_DOMAIN_DEVICE_PANIC:
>>>> +    case VIR_DOMAIN_DEVICE_MEMORY:
>>>> +    case VIR_DOMAIN_DEVICE_IOMMU:
>>>> +    case VIR_DOMAIN_DEVICE_VSOCK:
>>> Did you validate that all of the above can be used with zPCI?
>> Yes, I did. But how far can zPCI be used is a question. I make sure that
>> if their address
>> type can be PCI type zPCI address could be expanded. But we don't
>> guarantee they can
>> be really used in qemu. Like RNG device can't be used because it doesn't
>> support MSIx
>> which is required on S390.
> If that's the case, I'm not sure the current solution is what we
> want: if someone creates a guest and includes a RNG device in the
> configuration, they probably expect it to, well, work. IIUC, with
> the current implementation they would get a non-working RNG device
> instead, which certainly feels suboptimal.
Actually the guest can't startup with RNG device instead of a running guest
with a non-working RNG device and qemu would report error. The user can
get the information regarding startup failure. I think this is proper.
If RNG could support MSIx in future, we won't need to do any thing in 
Libvirt.
>
>>> [...]
>>>> +static virDomainPCIAddressExtensionFlags
>>>> +qemuDomainDeviceCalculatePCIAddressExtensionFlags(virQEMUCapsPtr qemuCaps,
>>>> +                                                  virDomainDeviceDefPtr dev)
>>>> +{
>>>> +    virDomainPCIAddressExtensionFlags extFlags = 0;
>>>> +
>>>> +    if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_ZPCI) &&
>>>> +        qemuDomainDeviceSupportZPCI(dev))
>>>> +        extFlags |= VIR_PCI_ADDRESS_EXTENSION_ZPCI;
>>> The libvirt code style guidelines[1] state that this should be
>>> formatted as
>>>
>>>     if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_ZPCI) &&
>>>         qemuDomainDeviceSupportZPCI(dev)) {
>>>         extFlags |= VIR_PCI_ADDRESS_EXTENSION_ZPCI;
>>>     }
>>>
>>> [1] https://libvirt.org/hacking.html
>> I see a lot of code in libvirt use this style. Is it new guideline?
> It's certainly been around for the past 3+ years. There's a lot of
> code in libvirt that's *way* older than that, though :)
>

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