8:38 a.m.
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
7:03 p.m.
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'"),
2:19 a.m.
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 ?
> "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.
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
10:42 a.m.
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
3468
days inactive
3470
days old
3 comments
2 participants
participants (2)
-
Cole Robinson -
Pavel Fedin