[libvirt] [PATCH v2 7/7] qemu: Unify generation of command line for virtio devices

Ján Tomko jtomko at redhat.com
Thu Sep 6 13:15:39 UTC 2018


On Thu, Sep 06, 2018 at 02:22:19PM +0200, Andrea Bolognani wrote:
>A virtio device such as
>
>  <controller type='scsi' model='virtio-scsi'/>
>
>will be translated to one of four different QEMU devices
>based on the address type. This behavior is the same for
>all virtio devices, but unfortunately we have separate
>ad-hoc code dealing with each and every one of them: not
>only this is pointless duplication, but it turns out
>that most of that code is not robust against new address
>types being introduced and some of it is outright buggy.
>
>Introduce a new function, qemuBuildVirtioDevStr(), which
>deals with the issue in a generic fashion, and rewrite
>all existing code to use it.
>
>This fixes a bunch of issues such as virtio-serial-pci
>being used with virtio-mmio addresses and virtio-gpu
>not being usable at all with virtio-mmio addresses.
>
>It also introduces a couple of minor regressions,
>namely no longer erroring out when attempting to
>use virtio-balloon and virtio-input devices with
>virtio-s390 addresses; that said, virtio-s390 has
>been superseded by virtio-ccw such a long time ago
>that recent QEMU releases have dropped support for
>the former entirely,

I approve of such disregard for antique virtio.

>so re-implementing such
>device-specific validation is not worth it.
>
>Signed-off-by: Andrea Bolognani <abologna at redhat.com>
>---
> src/qemu/qemu_command.c | 181 ++++++++++++++++++----------------------
> 1 file changed, 81 insertions(+), 100 deletions(-)
>
>diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
>index db7c3ad698..041e4bd7fb 100644
>--- a/src/qemu/qemu_command.c
>+++ b/src/qemu/qemu_command.c
>@@ -397,6 +397,59 @@ qemuBuildDeviceAddressStr(virBufferPtr buf,
>     return ret;
> }
>
>+
>+static int
>+qemuBuildVirtioDevStr(virBufferPtr buf,
>+                      const char *baseName,
>+                      virDomainDeviceAddressType type)
>+{
>+    const char *implName = NULL;
>+    int ret = -1;
>+
>+    switch (type) {
>+    case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI:
>+        implName = "pci";
>+        break;
>+
>+    case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO:
>+        implName = "device";
>+        break;
>+
>+    case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW:
>+        implName = "ccw";
>+        break;
>+
>+    case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_S390:
>+        implName = "s390";
>+        break;
>+
>+    case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DRIVE:
>+    case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_SERIAL:
>+    case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCID:
>+    case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_USB:
>+    case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO:
>+    case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_ISA:
>+    case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DIMM:
>+        virReportError(VIR_ERR_INTERNAL_ERROR,
>+                       _("Unexpected address type for '%s'"), baseName);
>+        goto done;

Just return -1;

>+
>+    case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE:
>+    case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_LAST:
>+    default:
>+        virReportEnumRangeError(virDomainDeviceAddressType, type);
>+        goto done;

Here too.

It's unlikely we'll end up having to do something worth cleaning up
before we even validate the supplied parameters.

>+    }
>+
>+    virBufferAsprintf(buf, "%s-%s", baseName, implName);
>+

>+    ret = 0;
>+
>+ done:
>+    return ret;

Then this can be simply:

return 0;

Reviewed-by: Ján Tomko <jtomko at redhat.com>

Jano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180906/ebe90ddc/attachment-0001.sig>


More information about the libvir-list mailing list