[libvirt] [PATCH] Allow PCI virtio on ARM "virt" machine
Virt machine in qemu has PCI generic host controller, and can use PCI devices. This provides performance improvement as well as vhost-net with irqfd support for virtio-net. However libvirt still insists on virtio devices attached to Virt machine to have MMIO bindings. This patch allows to use both. If the user doesn't specify <address type='virtio-mmio'>, PCI will be used by default. "virt-" prefix is intentionally ignored in third chunk because it is a temporary thing and qemu developers agreed to use "gic version" option, for which there is already support in libvirt. --- src/qemu/qemu_command.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 81e89fc..0580a37 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -457,7 +457,7 @@ qemuDomainSupportsNicdev(virDomainDefPtr def, /* non-virtio ARM nics require legacy -net nic */ if (((def->os.arch == VIR_ARCH_ARMV7L) || (def->os.arch == VIR_ARCH_AARCH64)) && - net->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO) + strcmp(net->model, "virtio")) return false; return true; @@ -1374,9 +1374,7 @@ qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr def, { if (((def->os.arch == VIR_ARCH_ARMV7L) || (def->os.arch == VIR_ARCH_AARCH64)) && - (STRPREFIX(def->os.machine, "vexpress-") || - STREQ(def->os.machine, "virt") || - STRPREFIX(def->os.machine, "virt-")) && + STRPREFIX(def->os.machine, "vexpress-") && virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MMIO)) { qemuDomainPrimeVirtioDeviceAddresses( def, VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO); @@ -2501,6 +2499,12 @@ qemuAssignDevicePCISlots(virDomainDefPtr def, VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW) continue; + if (((def->os.arch == VIR_ARCH_ARMV7L) || + (def->os.arch == VIR_ARCH_AARCH64)) && + STREQ(def->os.machine, "virt") && + def->disks[i]->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO) + continue; + if (def->disks[i]->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("virtio disk cannot have an address of type '%s'"), -- 1.9.5.msysgit.0
On 05/24/2015 09:38 AM, Pavel Fedin wrote:
Virt machine in qemu has PCI generic host controller, and can use PCI devices. This provides performance improvement as well as vhost-net with irqfd support for virtio-net. However libvirt still insists on virtio devices attached to Virt machine to have MMIO bindings. This patch allows to use both. If the user doesn't specify <address type='virtio-mmio'>, PCI will be used by default.
This patch breaks make check, since there's test cases that depend on the virtio-mmio behavior. I think you'll need to add a new qemu capabilities flag like QEMU_CAPS_AARCH64_VIRT_PCI that's enabled for qemu 2.3.0 or later... if it's available, then we default to PCI. After that we will definitely want to add test cases to exercise this new behavior. Another thing is we probably need to extend the XML parser to add a <controller type='pci'> automatically like we do for x86. I can help with some of this if you want, just let me know.
"virt-" prefix is intentionally ignored in third chunk because it is a temporary thing and qemu developers agreed to use "gic version" option, for which there is already support in libvirt.
I don't follow this, can you expand a bit? Maybe Michal can explain too since he did the libvirt gic patches Thanks, Cole
--- src/qemu/qemu_command.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 81e89fc..0580a37 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -457,7 +457,7 @@ qemuDomainSupportsNicdev(virDomainDefPtr def, /* non-virtio ARM nics require legacy -net nic */ if (((def->os.arch == VIR_ARCH_ARMV7L) || (def->os.arch == VIR_ARCH_AARCH64)) && - net->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO) + strcmp(net->model, "virtio")) return false;
return true; @@ -1374,9 +1374,7 @@ qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr def, { if (((def->os.arch == VIR_ARCH_ARMV7L) || (def->os.arch == VIR_ARCH_AARCH64)) && - (STRPREFIX(def->os.machine, "vexpress-") || - STREQ(def->os.machine, "virt") || - STRPREFIX(def->os.machine, "virt-")) && + STRPREFIX(def->os.machine, "vexpress-") && virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MMIO)) { qemuDomainPrimeVirtioDeviceAddresses( def, VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO); @@ -2501,6 +2499,12 @@ qemuAssignDevicePCISlots(virDomainDefPtr def, VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW) continue;
+ if (((def->os.arch == VIR_ARCH_ARMV7L) || + (def->os.arch == VIR_ARCH_AARCH64)) && + STREQ(def->os.machine, "virt") && + def->disks[i]->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO) + continue; + if (def->disks[i]->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("virtio disk cannot have an address of type '%s'"),
Hi!
I think you'll need to add a new qemu capabilities flag like QEMU_CAPS_AARCH64_VIRT_PCI that's enabled for qemu 2.3.0 or later... if it's available, then we default to PCI.
"virt-" prefix is intentionally ignored in third chunk because it is a temporary
How could i check for this ? Actually qemu already has PCI for both 32 and 64-bit virt board for quite some time. But the only way to check this is to run qemu. It does not expose any additional options for that. Or do you suggest just to check version number ? thing
and qemu developers agreed to use "gic version" option, for which there is already support in libvirt.
I don't follow this, can you expand a bit? Maybe Michal can explain too since he did the libvirt gic patches
Sorry, ignore this because i was telling crap :) I suggested that it was added just in case, because we are working on qemu mailing list on implementing GICv3 support, and my current solution is to add a new "virt-v3" machine. I tried an option but there are some technical difficulties about it. So perhaps it will stay "virt-v3" or "virt-gicv3" or something like that. But i found this commit in libvirt history, and it is explained that it's actually for distro maintainers who might want to add their own virt-something machines.
Another thing is we probably need to extend the XML parser to add a <controller type='pci'> automatically like we do for x86.
I can help with some of this if you want, just let me know.
Yes, please, would be nice because i'm not much into that XML stuff... I've seen notations like address type='pci' and then it's necessary to specify the location. But this requires some extra magic, like i need to specify that the machine has a controller (otherwise libvirt complains that i don't have a free slot), and i'm not sure that all these problems make sense for qemu, since qemu (AFAIK) does not allow to explicitly pin down devices on the PCI bus. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
On 05/26/2015 03:19 AM, Pavel Fedin wrote:
Hi!
I think you'll need to add a new qemu capabilities flag like QEMU_CAPS_AARCH64_VIRT_PCI that's enabled for qemu 2.3.0 or later... if it's available, then we default to PCI.
How could i check for this ? Actually qemu already has PCI for both 32 and 64-bit virt board for quite some time. But the only way to check this is to run qemu. It does not expose any additional options for that. Or do you suggest just to check version number ?
Yes you'd likely need to tie it to qemu version number. From looking at the git log I though this was only available in qemu 2.3.0 and later but it sounds like you are saying it has been around longer...
"virt-" prefix is intentionally ignored in third chunk because it is a temporary thing and qemu developers agreed to use "gic version" option, for which there is already support in libvirt.
I don't follow this, can you expand a bit? Maybe Michal can explain too since he did the libvirt gic patches
Sorry, ignore this because i was telling crap :) I suggested that it was added just in case, because we are working on qemu mailing list on implementing GICv3 support, and my current solution is to add a new "virt-v3" machine. I tried an option but there are some technical difficulties about it. So perhaps it will stay "virt-v3" or "virt-gicv3" or something like that. But i found this commit in libvirt history, and it is explained that it's actually for distro maintainers who might want to add their own virt-something machines.
Ah okay. I though you were saying that new -M virt behavior would be keyed off of some gic= value or something like that. We really should get -M virt versioning sooner rather than later though, especially with stuff like PCI support being added.
Another thing is we probably need to extend the XML parser to add a <controller type='pci'> automatically like we do for x86.
I can help with some of this if you want, just let me know.
Yes, please, would be nice because i'm not much into that XML stuff... I've seen notations like address type='pci' and then it's necessary to specify the location. But this requires some extra magic, like i need to specify that the machine has a controller (otherwise libvirt complains that i don't have a free slot), and i'm not sure that all these problems make sense for qemu, since qemu (AFAIK) does not allow to explicitly pin down devices on the PCI bus.
For x86 you definitely can specify PCI device addresses via -device, but maybe that doesn't apply here. I'll see if I can get some time to look at this stuff before end of the week. - Cole
participants (2)
-
Cole Robinson -
Pavel Fedin