[libvirt] [PATCH v2 0/3] Add support for gic-version machine option
qemu now supports gic-version option for the virt machine. This patchset allows to use it in libvirt. v1 => v2: - Added capability flag Pavel Fedin (3): qemu: Introduce QEMU_CAPS_MACH_VIRT_GIC_VERSION capability qemu: Add support for gic-version machine option qemu: Add test cases for gic-version option src/qemu/qemu_capabilities.c | 5 +++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 43 +++++++++++++++------- .../qemuxml2argv-aarch64-gicv3.args | 6 +++ .../qemuxml2argv-aarch64-gicv3.xml | 26 +++++++++++++ tests/qemuxml2argvtest.c | 5 +++ 6 files changed, 73 insertions(+), 13 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gicv3.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gicv3.xml -- 2.1.4
Unfortunately qemu currently doesn't offer introspection for machine types, so we have to rely on version number, similar to QEMU_CAPS_MACHINE_USB_OPT. Signed-off-by: Pavel Fedin <p.fedin@samsung.com> --- src/qemu/qemu_capabilities.c | 5 +++++ src/qemu/qemu_capabilities.h | 1 + 2 files changed, 6 insertions(+) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index eb2edf5..98d306c 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -298,6 +298,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST, "rtl8139", "e1000", "virtio-net", + "gic-version", ); @@ -3404,6 +3405,10 @@ virQEMUCapsInitQMPMonitor(virQEMUCapsPtr qemuCaps, if (qemuCaps->version >= 2004000) virQEMUCapsSet(qemuCaps, QEMU_CAPS_VHOSTUSER_MULTIQUEUE); + /* Since 2.4.50 ARM virt machine supports gic-version option */ + if (qemuCaps->version >= 2004050) + virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACH_VIRT_GIC_VERSION); + if (virQEMUCapsProbeQMPCommands(qemuCaps, mon) < 0) goto cleanup; if (virQEMUCapsProbeQMPEvents(qemuCaps, mon) < 0) diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h index 2623574..a1d98d0 100644 --- a/src/qemu/qemu_capabilities.h +++ b/src/qemu/qemu_capabilities.h @@ -238,6 +238,7 @@ typedef enum { QEMU_CAPS_DEVICE_RTL8139 = 196, /* -device rtl8139 */ QEMU_CAPS_DEVICE_E1000 = 197, /* -device e1000 */ QEMU_CAPS_DEVICE_VIRTIO_NET = 198, /* -device virtio-net-* */ + QEMU_CAPS_MACH_VIRT_GIC_VERSION = 199, /* -machine virt,gic-version */ QEMU_CAPS_LAST, /* this must always be the last item */ } virQEMUCapsFlags; -- 2.1.4
Support for GICv3 has been recently introduced in qemu using gic-version option for the 'virt' machine. The option can actually take values of '2', '3' and 'host', however, since in libvirt this is a numeric parameter, we limit it only to 2 and 3. Value of 2 is not added to the command line in order to keep backward compatibility with older qemu versions. Signed-off-by: Pavel Fedin <p.fedin@samsung.com> --- src/qemu/qemu_command.c | 43 ++++++++++++++++++++++++++++++------------- 1 file changed, 30 insertions(+), 13 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index bb1835c..a47e188 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -7702,19 +7702,6 @@ qemuBuildCpuArgStr(virQEMUDriverPtr driver, have_cpu = true; } - if (def->features[VIR_DOMAIN_FEATURE_GIC] == VIR_TRISTATE_SWITCH_ON) { - if (def->gic_version && def->gic_version != 2) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - _("gic version '%u' is not supported"), - def->gic_version); - goto cleanup; - } - - /* There's no command line argument currently to turn on/off GIC. It's - * done automatically by qemu-system-aarch64. But if this changes, lets - * put the code here. */ - } - if (virBufferCheckError(&buf) < 0) goto cleanup; @@ -7931,6 +7918,36 @@ qemuBuildMachineArgStr(virCommandPtr cmd, return -1; } + if (def->features[VIR_DOMAIN_FEATURE_GIC] == VIR_TRISTATE_SWITCH_ON) { + if (def->gic_version) { + if (!STREQ(def->os.machine, "virt") && + !STRPREFIX(def->os.machine, "virt-")) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("gic-version option is available " + "only for virt machine")); + virBufferFreeAndReset(&buf); + return -1; + } + + /* 2 is the default, so we don't put it as option for + * backwards compatibility + */ + if (def->gic_version != 2) { + if (virQEMUCapsGet(qemuCaps, + QEMU_CAPS_MACH_VIRT_GIC_VERSION)) { + virBufferAsprintf(&buf, ",gic-version=%d", + def->gic_version); + } else { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("gic-version option is not available " + "with this QEMU binary")); + virBufferFreeAndReset(&buf); + return -1; + } + } + } + } + virCommandAddArgBuffer(cmd, &buf); } -- 2.1.4
On Wed, Sep 30, 2015 at 02:04:10PM +0300, Pavel Fedin wrote:
Support for GICv3 has been recently introduced in qemu using gic-version option for the 'virt' machine. The option can actually take values of '2', '3' and 'host', however, since in libvirt this is a numeric parameter, we limit it only to 2 and 3. Value of 2 is not added to the command line in order to keep backward compatibility with older qemu versions.
Signed-off-by: Pavel Fedin <p.fedin@samsung.com> --- src/qemu/qemu_command.c | 43 ++++++++++++++++++++++++++++++------------- 1 file changed, 30 insertions(+), 13 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index bb1835c..a47e188 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -7702,19 +7702,6 @@ qemuBuildCpuArgStr(virQEMUDriverPtr driver, have_cpu = true; }
- if (def->features[VIR_DOMAIN_FEATURE_GIC] == VIR_TRISTATE_SWITCH_ON) { - if (def->gic_version && def->gic_version != 2) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - _("gic version '%u' is not supported"), - def->gic_version); - goto cleanup; - } - - /* There's no command line argument currently to turn on/off GIC. It's - * done automatically by qemu-system-aarch64. But if this changes, lets - * put the code here. */ - } - if (virBufferCheckError(&buf) < 0) goto cleanup;
@@ -7931,6 +7918,36 @@ qemuBuildMachineArgStr(virCommandPtr cmd, return -1; }
+ if (def->features[VIR_DOMAIN_FEATURE_GIC] == VIR_TRISTATE_SWITCH_ON) { + if (def->gic_version) { + if (!STREQ(def->os.machine, "virt") && + !STRPREFIX(def->os.machine, "virt-")) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("gic-version option is available " + "only for virt machine")); + virBufferFreeAndReset(&buf); + return -1; + }
Indentation's off here. Also before this patch we would allow def->gic_version == 2 for any machine type. I don't have a problem with this since GIC doesn't make sense anywhere else then on ARM machines, but shouldn't we check for the fact that the request is for ARM (in case, for example, if ppc64 gains some 'virt' machine type)? Because we have no guarantee that it's ARM just based on the machine type.
+ + /* 2 is the default, so we don't put it as option for + * backwards compatibility + */ + if (def->gic_version != 2) { + if (virQEMUCapsGet(qemuCaps, + QEMU_CAPS_MACH_VIRT_GIC_VERSION)) { + virBufferAsprintf(&buf, ",gic-version=%d", + def->gic_version); + } else { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("gic-version option is not available " + "with this QEMU binary")); + virBufferFreeAndReset(&buf); + return -1;
I'd change this to: if (gic != 2) { if (!caps) error; append_cmd(); } If you're ok with that, just let me know and I'll push it with the following diff squashed in, right after the release: diff --git i/src/qemu/qemu_command.c w/src/qemu/qemu_command.c index a47e1883d976..72149bdd1eef 100644 --- i/src/qemu/qemu_command.c +++ w/src/qemu/qemu_command.c @@ -7918,35 +7918,36 @@ qemuBuildMachineArgStr(virCommandPtr cmd, return -1; } - if (def->features[VIR_DOMAIN_FEATURE_GIC] == VIR_TRISTATE_SWITCH_ON) { - if (def->gic_version) { - if (!STREQ(def->os.machine, "virt") && - !STRPREFIX(def->os.machine, "virt-")) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + if (def->features[VIR_DOMAIN_FEATURE_GIC] == VIR_TRISTATE_SWITCH_ON) { + if (def->gic_version) { + if ((def->os.arch != VIR_ARCH_ARMV7L && + def->os.arch != VIR_ARCH_AARCH64) || + (STRNEQ(def->os.machine, "virt") && + !STRPREFIX(def->os.machine, "virt-"))) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("gic-version option is available " "only for virt machine")); virBufferFreeAndReset(&buf); return -1; - } + } - /* 2 is the default, so we don't put it as option for - * backwards compatibility - */ + /* 2 is the default, so we don't put it as option for + * backwards compatibility + */ if (def->gic_version != 2) { - if (virQEMUCapsGet(qemuCaps, - QEMU_CAPS_MACH_VIRT_GIC_VERSION)) { - virBufferAsprintf(&buf, ",gic-version=%d", - def->gic_version); - } else { + if (!virQEMUCapsGet(qemuCaps, + QEMU_CAPS_MACH_VIRT_GIC_VERSION)) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("gic-version option is not available " "with this QEMU binary")); virBufferFreeAndReset(&buf); return -1; } + + virBufferAsprintf(&buf, ",gic-version=%d", def->gic_version); } - } - } + } + } virCommandAddArgBuffer(cmd, &buf); } -- Martin
Hello!
Indentation's off here.
Damn, sorry, overlooked...
Also before this patch we would allow def->gic_version == 2 for any machine type. I don't have a problem with this since GIC doesn't make sense anywhere else then on ARM machines,
I'm OK with this. I used 0 for 'no version supplied' just because libvirt originally does this.
but shouldn't we check for the fact that the request is for ARM (in case, for example, if ppc64 gains some 'virt' machine type)? Because we have no guarantee that it's ARM just based on the machine type.
Yes, i guess we should.
I'd change this to:
if (gic != 2) { if (!caps) error; append_cmd(); }
You know, if we are talking about making changes in parser code, we could do more. Actually, as i said in my cover letter, qemu supports more than just 2 or 3. We can also specify 'host' for 'best possible'. Could we accommodate this somehow too? I believe in order to do this, we should change parameter type from numeric to string. And also we could add some another boolean, which would allow to disable in-kernel GIC emulation (kernel_irqchip=off). This works with any machine type, BTW, not only with ARM. Something like <gic kvm='off'/>. I believe these changes could go as a separate patch, after we discuss details.
If you're ok with that, just let me know and I'll push it with the following diff squashed in, right after the release:
Yes, ACK.
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("gic-version option is available " "only for virt machine"));
Then "...only for ARM virt machine". Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
On Thu, Oct 01, 2015 at 09:53:00AM +0300, Pavel Fedin wrote:
Hello!
Indentation's off here.
Damn, sorry, overlooked...
Also before this patch we would allow def->gic_version == 2 for any machine type. I don't have a problem with this since GIC doesn't make sense anywhere else then on ARM machines,
I'm OK with this. I used 0 for 'no version supplied' just because libvirt originally does this.
but shouldn't we check for the fact that the request is for ARM (in case, for example, if ppc64 gains some 'virt' machine type)? Because we have no guarantee that it's ARM just based on the machine type.
Yes, i guess we should.
I'd change this to:
if (gic != 2) { if (!caps) error; append_cmd(); }
You know, if we are talking about making changes in parser code, we could do more. Actually, as i said in my cover letter, qemu supports more than just 2 or 3. We can also specify 'host' for 'best possible'. Could we accommodate this somehow too? I believe in order to do this, we should change parameter type from numeric to string.
Yes, we can certainly do that.
And also we could add some another boolean, which would allow to disable in-kernel GIC emulation (kernel_irqchip=off). This works with any machine type, BTW, not only with ARM. Something like <gic kvm='off'/>.
I don't know what that is. Is that only GIC related? Where could I find more details? If that makes sense for anything, we can sure do that, the only reason why I would be against this, which I can come up now, is if there is nobody using it.
I believe these changes could go as a separate patch, after we discuss details.
Yeah, sure.
If you're ok with that, just let me know and I'll push it with the following diff squashed in, right after the release:
Yes, ACK.
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("gic-version option is available " "only for virt machine"));
Then "...only for ARM virt machine".
Oh, good catch, I'll fix that, thanks.
Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
Hello!
And also we could add some another boolean, which would allow to disable in-kernel GIC emulation (kernel_irqchip=off). This works with any machine type, BTW, not only with ARM. Something like <gic kvm='off'/>.
I don't know what that is. Is that only GIC related?
No, not only GIC. It applies to any possible irqchip. When set to off, this option disables using KVM acceleration for the irqchip, and qemu's software emulation is used instead.
Where could I find more details?
Something like "aarch64-system-qemu -machine virt,?" i guess. Or similar command line for different arch and different machine. It is implemented as machine option, but applies to any machine, not only to virt, and not only for ARM. The option is also mentioned on http://wiki.qemu.org/KVM, but information is outdated (it defaults to on since long ago).
If that makes sense for anything, we can sure do that, the only reason why I would be against this, which I can come up now, is if there is nobody using it.
Yes, this option was bitrot in the ARM kernel, but i have recently fixed it (https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=... 945f1765cd48eb0da). I understand that the primary use of this on e.g. x86 would be for testing purposes only, but for ARM it can be more useful, because you cannot run everything on everything. For example, if you want GICv2 system, but your host is pure GICv3 without backwards compatibility, you could want to use this option, so that you use software-emulated GICv2. Of course this would not give you the top performance, but this is still usable, i tested it. Perhaps other systems, like PowerPC, can also take advantage of it (from KVM code i see there are several different irqchips for PPC, and i'm in doubt that any of these irqchips can emulate everything else). There is one more complication with this option - CP15 timer currently will not work, because virtual timer accesses cannot be intercepted by the hypervisor. I am considering fixing this in the future, there are at least two possible solutions. But, still, you can run, for example, vexpress guest with a little bit patched device tree or reconfigured kernel (arch-timer disabled), because this hardware has another, memory-mapped timer, which can be used with software emulation. And it works. Well, if you think that this is not ready for the wide public yet, we can leave out this part. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
These tests make sure that we can use this option only when the capability is set. Signed-off-by: Pavel Fedin <p.fedin@samsung.com> --- .../qemuxml2argv-aarch64-gicv3.args | 6 +++++ .../qemuxml2argv-aarch64-gicv3.xml | 26 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 5 +++++ 3 files changed, 37 insertions(+) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gicv3.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gicv3.xml diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gicv3.args b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gicv3.args new file mode 100644 index 0000000..d697669 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gicv3.args @@ -0,0 +1,6 @@ +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-aarch64 -S -machine virt,accel=tcg,gic-version=3 -cpu cortex-a53 -m 1024 -smp 1 \ +-nographic -nodefaults -monitor unix:/tmp/test-monitor,server,nowait -boot c \ +-kernel /aarch64.kernel -initrd /aarch64.initrd -append console=ttyAMA0 -usb \ +-net nic,macaddr=52:54:00:09:a4:37,vlan=0,model=virtio,name=net0 \ +-net user,vlan=0,name=hostnet0 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gicv3.xml b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gicv3.xml new file mode 100644 index 0000000..f8d63c3 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gicv3.xml @@ -0,0 +1,26 @@ +<domain type="qemu"> + <name>aarch64test</name> + <uuid>6ba410c5-1e5c-4d57-bee7-2228e7ffa32f</uuid> + <memory>1048576</memory> + <currentMemory>1048576</currentMemory> + <vcpu>1</vcpu> + <features> + <acpi/> + <gic version='3'/> + </features> + <cpu match='exact'> + <model>cortex-a53</model> + </cpu> + <os> + <type arch="aarch64" machine="virt">hvm</type> + <kernel>/aarch64.kernel</kernel> + <initrd>/aarch64.initrd</initrd> + <cmdline>console=ttyAMA0</cmdline> + </os> + <devices> + <emulator>/usr/bin/qemu-system-aarch64</emulator> + <interface type='user'> + <mac address='52:54:00:09:a4:37'/> + </interface> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index ae67779..e6bf2f1 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -1644,6 +1644,11 @@ mymain(void) QEMU_CAPS_CPU_HOST, QEMU_CAPS_KVM); DO_TEST("aarch64-gic", QEMU_CAPS_DEVICE, QEMU_CAPS_DRIVE, QEMU_CAPS_KVM); + DO_TEST("aarch64-gicv3", QEMU_CAPS_DEVICE, QEMU_CAPS_DRIVE, + QEMU_CAPS_KVM, QEMU_CAPS_MACHINE_OPT, + QEMU_CAPS_MACH_VIRT_GIC_VERSION); + DO_TEST_FAILURE("aarch64-gicv3", QEMU_CAPS_DEVICE, QEMU_CAPS_DRIVE, + QEMU_CAPS_KVM, QEMU_CAPS_MACHINE_OPT); driver.caps->host.cpu->arch = VIR_ARCH_AARCH64; DO_TEST("aarch64-kvm-32-on-64", QEMU_CAPS_DEVICE, QEMU_CAPS_DRIVE, -- 2.1.4
On Wed, Sep 30, 2015 at 02:04:08PM +0300, Pavel Fedin wrote:
qemu now supports gic-version option for the virt machine. This patchset allows to use it in libvirt.
v1 => v2: - Added capability flag
ACK series after release with my diff squashed in in case the original author agrees.
Pavel Fedin (3): qemu: Introduce QEMU_CAPS_MACH_VIRT_GIC_VERSION capability qemu: Add support for gic-version machine option qemu: Add test cases for gic-version option
src/qemu/qemu_capabilities.c | 5 +++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 43 +++++++++++++++------- .../qemuxml2argv-aarch64-gicv3.args | 6 +++ .../qemuxml2argv-aarch64-gicv3.xml | 26 +++++++++++++ tests/qemuxml2argvtest.c | 5 +++ 6 files changed, 73 insertions(+), 13 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gicv3.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gicv3.xml
-- 2.1.4
On 09/30/2015 07:04 AM, Pavel Fedin wrote:
qemu now supports gic-version option for the virt machine. This patchset allows to use it in libvirt.
This isn't specifically related to your patch, but I'm curious: Can you explain what this setting actually does? When would apps like virt-manager want to enable it? - Cole
Hello!
Can you explain what this setting actually does?
Of course. It allows to choose GIC version used by ARM 'virt' machine. By default it's 2, but you can now set it to 3. Actually, initially i proposed another machine type, like 'virt-v3', IMHO this would be more logical because this is kind of different architecture. But Peter Maydell disagreed and insisted on option. So we have an option.
When would apps like virt-manager want to enable it?
When choosing 'virt' machine type for ARM architecture. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
On Thu, Oct 01, 2015 at 10:00:13AM +0300, Pavel Fedin wrote:
Hello!
Can you explain what this setting actually does?
Of course. It allows to choose GIC version used by ARM 'virt' machine. By default it's 2, but you can now set it to 3. Actually, initially i proposed another machine type, like 'virt-v3', IMHO this would be more logical because this is kind of different architecture. But Peter Maydell disagreed and insisted on option. So we have an option.
I think Cole wanted to know more like how it can be useful for end users. Since I see GIC as something similar to APIC, I'm guessing the usefulness won't be directly visible, but should help. About what exactly it does or what are the differences between, that I cannot help with, unfortunately.
When would apps like virt-manager want to enable it?
When choosing 'virt' machine type for ARM architecture.
Unconditionally? Doesn't that pose a problem, e.g. for requesting version that is not supported or breaking something that expects lower version?
Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
Hello!
I think Cole wanted to know more like how it can be useful for end users. Since I see GIC as something similar to APIC, I'm guessing the usefulness won't be directly visible, but should help. About what exactly it does or what are the differences between, that I cannot help with, unfortunately.
Ah, i assumed you know ARM architecture, sorry. So, GIC for ARM is really what is APIC for x86. It's an interrupt controller. There are several generations of this controller, up to 3 as of now (there is spec for v4, but i don't know any real-life implementation, additionally it's fully compatible with v3). v1 is really obsolete, and AFAIK v2 is fully compatible with it, so for us the only important ones are v2 and v3. v2 is what was included into the majority of ARM32 systems. Some ARM64 systems use it too, but it has a number of limitations. The largest one is that it cannot support more than 16 CPUs. In order to overcome this, GICv3 was developed. GICv3 is significantly different from GICv2, so it requires own implementation, and own kernel driver. The next thing concerns virtualization, and here comes our qemu support. GICv3 can include backwards v2 compatibility, but only as an option. And, for example, on my board there's no such option. Therefore, in order to be able to use KVM GIC acceleration, you have to emulate GICv3 guest on such a host. You simply will be unable to run GICv2 guest under KVM in this case. So, "GIC type" setting should be thought of like a "board subtype". This is different hardware, with different software support.
When choosing 'virt' machine type for ARM architecture.
Unconditionally? Doesn't that pose a problem, e.g. for requesting version that is not supported
It shouldn't. If you specify version unsupported by qemu, qemu will complain. I guess, the same with any other option.
or breaking something that expects lower version?
qemu's policy is to default to 2. libvirt's policy is NOT to specify gic-version property unless value different from 2 is explicitly specified in the XML. I guess, virt-manager could also default to '2' (or 'Hypervisor's default', which would be the same). Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
participants (3)
-
Cole Robinson -
Martin Kletzander -
Pavel Fedin