Re: [libvirt] [Qemu-devel] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines

[Jason J. Herne]

On 10/20/2017 10:54 AM, Christian Borntraeger wrote:

Starting a guest with

 hvm
   
   

on an IBM z14 results in

"qemu-system-s390x: Some features requested in the CPU model are not
available in the configuration: gs"

This is because guarded storage is fenced for compat machines that did not have
guarded storage support, but libvirt expands the cpu model according to the
latest available machine.

While this prevents future migration abort (by not starting the guest at all),
not being able to start a "host-model" guest is very much unexpected.  As it
turns out, even if we would modify libvirt to not expand the cpu model to
contain "gs" for compat machines, it cannot guarantee that a migration will
succeed. For example if the kernel changes its features (or the user has
nested=1 on one host but not on the other) the migration will fail
nevertheless.  So instead of fencing "gs" for machines <= 2.9 lets allow it for
all machine types that support the CPU model. This will make "host-model"
runnable all the time, while relying on the CPU model to reject invalid
migration attempts.

...

-if (gs_allowed()) {
+if (cpu_model_allowed()) {
  if (kvm_vm_enable_cap(s, KVM_CAP_S390_GS, 0) == 0) {
  cap_gs = 1;


Ok, honestly, I dislike this idea because it means we are effectively 
lying now. We will happily accept a +gs cpu model with a 2.9 compat 
machine when the point of compat machines is to mimick the older version 
of Qemu which does not support GS.  Yes, model checking will prevent the 
worst side effects, namely, exploding migrations.


I'd far prefer a solution that makes host-model dependent on the machine 
type. But I understand some of the backlash on that idea. Still, it 
seems like the cleanest approach even if it will be more work.


With all of that said, I know we want this fixed and your patch seems to 
fix the problem. So if you need an R-b...


Reviewed-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>

Can we have a new tag? :-D
Reviewed-by-with-reservations: Jason J. Herne <jjhe...@linux.vnet.ibm.com>

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] [Qemu-devel] [PATCH 0/9] i386: query-cpu-model-expansion test script

[Jason J. Herne]

On 01/18/2017 12:00 PM, Eduardo Habkost wrote:

On Tue, Jan 17, 2017 at 10:22:10AM -0500, Jason J. Herne wrote:

On 01/16/2017 08:01 PM, Eduardo Habkost wrote:

This is a follow-up to the series that implements
query-cpu-model-expansion. Before including the test script, the
series has some fixes to allow the results of
query-cpu-model-expansion to be used in the QEMU command-line.

The script probably will work on s390x too, but I couldn't test
it yet.



Eduardo,

This test seems to mostly work on s390. The only issue I ran into is
querying host model using tcg only. s390 requires kvm to query the host
model. Perhaps we could just skip the tcg host test case on s390?


We could still try to test "host", but add it to a greylist where
errors returned by query-cpu-model-expansion can be non-fatal.
query-cpu-model-expansion model="host" can also fail with KVM if
the host doesn't support CPU models.



David had the idea to just support -cpu host for tcg. We could do that.
In the meantime, I'm ok with your greylist idea too. This would allow the
script to work properly on s390 right from the start, and we can remove the
greylist when s390 supports specifying -cpu host for tcg.

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] [PATCH] qemu: Reset hostModelInfo in virQEMUCapsReset

[Jason J. Herne]

On 01/18/2017 10:50 AM, Jiri Denemark wrote:

Signed-off-by: Jiri Denemark <jdene...@redhat.com>
---
 src/qemu/qemu_capabilities.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 89e9dd471..1e1b53b22 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -3752,6 +3752,9 @@ virQEMUCapsReset(virQEMUCapsPtr qemuCaps)
 VIR_FREE(qemuCaps->gicCapabilities);
 qemuCaps->ngicCapabilities = 0;

+qemuMonitorCPUModelInfoFree(qemuCaps->hostCPUModelInfo);
+qemuCaps->hostCPUModelInfo = NULL;
+
 virCPUDefFree(qemuCaps->hostCPUModel);
 qemuCaps->hostCPUModel = NULL;
 }



Fwiw,

Looks good to me.

Reviewed-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] [Qemu-devel] [PATCH 0/9] i386: query-cpu-model-expansion test script

[Jason J. Herne]

On 01/16/2017 08:01 PM, Eduardo Habkost wrote:

This is a follow-up to the series that implements
query-cpu-model-expansion. Before including the test script, the
series has some fixes to allow the results of
query-cpu-model-expansion to be used in the QEMU command-line.

The script probably will work on s390x too, but I couldn't test
it yet.



Eduardo,

This test seems to mostly work on s390. The only issue I ran into is 
querying host model using tcg only. s390 requires kvm to query the host 
model. Perhaps we could just skip the tcg host test case on s390?



hernejj: ['/usr/local/bin/qemu-system-s390x', '-chardev', 
'socket,id=mon,path=/var/tmp/qom-fetch-monitor.sock', '-mon', 
'chardev=mon,mode=control', '-display', 'none', '-vga', 'none', 
'-qtest', 'unix:path=/var/tmp/qom-fetch-qtest.sock', '-qtest-log', 
'/dev/null', '-machine', 'accel=qtest', '-machine', 'accel=tcg', '-S', 
'-cpu', 'host']

qemu-system-s390x: CPU definition requires KVM
E
==
ERROR: testTCGModels (__main__.CPUModelTest)
--
Traceback (most recent call last):
  File "./query-cpu-model-test.py", line 380, in testTCGModels
self.checkAllCPUModels()
  File "./query-cpu-model-test.py", line 375, in checkAllCPUModels
self.checkOneCPUModel(m)
  File "./query-cpu-model-test.py", line 304, in checkOneCPUModel
self.checkExpansions(model, msg)
  File "./query-cpu-model-test.py", line 221, in checkExpansions
'%s.static' % (msg))
  File "./query-cpu-model-test.py", line 177, in checkOneExpansion
type=type, model=model['model'])
  File "./../scripts/qemu.py", line 185, in command
raise Exception(reply["error"]["desc"])
Exception: The CPU definition 'host' requires KVM

----------
Ran 2 tests in 74.622s


--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] [PATCH] qemu-capabilities: Fix query-cpu-model-expansion on s390 with older kernel

[Jason J. Herne]

On 01/13/2017 09:11 AM, Jiri Denemark wrote:

On Fri, Jan 13, 2017 at 11:04:21 +0100, Jiri Denemark wrote:

On Thu, Jan 12, 2017 at 11:18:11 -0500, Collin L. Walling wrote:

When running on s390 with a kernel that does not support cpu model checking and
with a Qemu new enough to support query-cpu-model-expansion, the gathering of 
qemu
capabilities will fail. Qemu responds to the query-cpu-model-expansion qmp
command with an error because the needed kernel ioct does not exist. When this
happens a guest cannot even be defined due to missing qemu capabilities data.

This patch fixes the problem by silently ignoring generic errors stemming from
calls to query-cpu-model-expansion.

Reported-by: Farhan Ali <al...@linux.vnet.ibm.com>
Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/qemu/qemu_monitor_json.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index e767437..1662749 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -5041,6 +5041,15 @@ qemuMonitorJSONGetCPUModelExpansion(qemuMonitorPtr mon,
 if (qemuMonitorJSONCommand(mon, cmd, ) < 0)
 goto cleanup;

+/* Some QEMU architectures have the query-cpu-model-expansion
+ * command, but return 'GenericError' instead of simply omitting
+ * the command entirely.
+ */


Hmm, this comment says something a bit different than the commit
message. I hope the issue described by this comment was fixed in QEMU
within the same release the query-cpu-model-expansion command was
introduced. But we need to fix this nevertheless to address what the
commit message describes.


+if (qemuMonitorJSONHasError(reply, "GenericError")) {
+ret = 0;
+goto cleanup;
+}
+
 if (qemuMonitorJSONCheckError(cmd, reply) < 0)
 goto cleanup;


However, we need to do a little bit more than just ignoring this error.
I'll send a v2 soon.


No I won't send the v2. I was wrong. I thought we should clear the
QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION capability when we detect the
command is not actually working, but we can't do that since the
existence of this command serves as an indicator of other CPU
configuration capabilities which cannot be probed directly. Thus just
ignoring non-working query-cpu-model-expansion command is the right
thing to do.

But I suggest to change the comment to something like the following:

/* Even though query-cpu-model-expansion is advertised by
 * query-commands it may just return GenericError if it is not
 * implemented for the requested guest architecture or it is not
 * supported in the host environment.
 */

ACK to this patch and please let me know if you agree with the modified
comment.



Jiri, yes, I agree with the comment change. Thanks for taking a look at 
this.


--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] [PATCH] qemu-capabilities: Fix query-cpu-model-expansion on s390 with older kernel

[Jason J. Herne]

On 01/13/2017 05:04 AM, Jiri Denemark wrote:

On Thu, Jan 12, 2017 at 11:18:11 -0500, Collin L. Walling wrote:

When running on s390 with a kernel that does not support cpu model checking and
with a Qemu new enough to support query-cpu-model-expansion, the gathering of 
qemu
capabilities will fail. Qemu responds to the query-cpu-model-expansion qmp
command with an error because the needed kernel ioct does not exist. When this
happens a guest cannot even be defined due to missing qemu capabilities data.

This patch fixes the problem by silently ignoring generic errors stemming from
calls to query-cpu-model-expansion.

Reported-by: Farhan Ali <al...@linux.vnet.ibm.com>
Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/qemu/qemu_monitor_json.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index e767437..1662749 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -5041,6 +5041,15 @@ qemuMonitorJSONGetCPUModelExpansion(qemuMonitorPtr mon,
 if (qemuMonitorJSONCommand(mon, cmd, ) < 0)
 goto cleanup;

+/* Some QEMU architectures have the query-cpu-model-expansion
+ * command, but return 'GenericError' instead of simply omitting
+ * the command entirely.
+ */


Hmm, this comment says something a bit different than the commit
message. I hope the issue described by this comment was fixed in QEMU
within the same release the query-cpu-model-expansion command was
introduced. But we need to fix this nevertheless to address what the
commit message describes.



The issue still exists in Qemu. I can work up a patch to handle it. My first
idea is to simply test that the ioctl exists and functions at Qemu
initialization and deregister the query-cpu-model-expansion command in the
event that the ioctl does not exist or fails. Thoughts?


However, we need to do a little bit more than just ignoring this error.
I'll send a v2 soon.


--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] [PATCH 0/9] Qemu: s390: Cpu Model Support

[Jason J. Herne]

On 12/18/2016 02:22 PM, Jason J. Herne wrote:

This patch set enables cpu model support for s390. The user can now set exact
cpu models, query supported models via virsh domcapabilities, and use host-model
and host-passthrough modes. The end result is that migration is safer because
Qemu will perform runnability checking on the destination host and quit with an
error if the guest's cpu model is not supported.

Note: Some test data has been separated from corresponding test case updates for
ease of review.


Just pinging since we've had a long break recently. Hope everyone enjoyed
their holidays.

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] [PATCH 0/9] Qemu: s390: Cpu Model Support

[Jason J. Herne]

On 12/18/2016 02:22 PM, Jason J. Herne wrote:

This patch set enables cpu model support for s390. The user can now set exact
cpu models, query supported models via virsh domcapabilities, and use host-model
and host-passthrough modes. The end result is that migration is safer because
Qemu will perform runnability checking on the destination host and quit with an
error if the guest's cpu model is not supported.


I forgot to add the v3 tag to the patches. My apologies. This is indeed 
v3 though.


--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

[libvirt] [PATCH 5/9] tests: qemu capabilites: qemu 2.7 and 2.8 on s390x

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

Tests Qemu capabilities on s390x before and after the availability of
the query-cpu-model-expansion QMP command.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 tests/qemucapabilitiestest.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/qemucapabilitiestest.c b/tests/qemucapabilitiestest.c
index 51d0cc4..f9c3456 100644
--- a/tests/qemucapabilitiestest.c
+++ b/tests/qemucapabilitiestest.c
@@ -172,6 +172,8 @@ mymain(void)
 DO_TEST("aarch64", "caps_2.6.0-gicv2");
 DO_TEST("aarch64", "caps_2.6.0-gicv3");
 DO_TEST("ppc64le", "caps_2.6.0");
+DO_TEST("s390x", "caps_2.7.0");
+DO_TEST("s390x", "caps_2.8.0");
 
 /*
  * Run "tests/qemucapsprobe /path/to/qemu/binary >foo.replies"
-- 
2.7.4

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

[libvirt] [PATCH 9/9] qemu: command: Support new cpu feature argument syntax

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

Qemu has abandoned the +/-feature syntax in favor of key=value. Some
architectures (s390) do not support +/-feature. So we update libvirt to handle
both formats.

If we detect a sufficiently new Qemu (indicated by support for qmp
query-cpu-model-expansion) we use key=value else we fall back to +/-feature.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/qemu/qemu_command.c| 18 +++--
 .../qemuxml2argv-cpu-s390-features.args| 19 ++
 .../qemuxml2argv-cpu-s390-features.xml | 23 ++
 tests/qemuxml2argvtest.c   |  2 ++
 4 files changed, 60 insertions(+), 2 deletions(-)
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-features.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-features.xml

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index f8e48d2..89226a6 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -6665,6 +6665,14 @@ qemuBuildCpuModelArgStr(virQEMUDriverPtr driver,
 break;
 }
 
+if (ARCH_IS_S390(def->os.arch) && cpu->features &&
+!virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION)) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+   _("CPU features not supported by hypervisor for %s "
+ "architecture"), virArchToString(def->os.arch));
+goto cleanup;
+}
+
 if (cpu->vendor_id)
 virBufferAsprintf(buf, ",vendor=%s", cpu->vendor_id);
 
@@ -6672,12 +6680,18 @@ qemuBuildCpuModelArgStr(virQEMUDriverPtr driver,
 switch ((virCPUFeaturePolicy) cpu->features[i].policy) {
 case VIR_CPU_FEATURE_FORCE:
 case VIR_CPU_FEATURE_REQUIRE:
-virBufferAsprintf(buf, ",+%s", cpu->features[i].name);
+if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION))
+virBufferAsprintf(buf, ",%s=on", cpu->features[i].name);
+else
+virBufferAsprintf(buf, ",+%s", cpu->features[i].name);
 break;
 
 case VIR_CPU_FEATURE_DISABLE:
 case VIR_CPU_FEATURE_FORBID:
-virBufferAsprintf(buf, ",-%s", cpu->features[i].name);
+if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION))
+virBufferAsprintf(buf, ",%s=off", cpu->features[i].name);
+else
+virBufferAsprintf(buf, ",-%s", cpu->features[i].name);
 break;
 
 case VIR_CPU_FEATURE_OPTIONAL:
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-features.args 
b/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-features.args
new file mode 100644
index 000..07abc93
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-features.args
@@ -0,0 +1,19 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-kvm \
+-name guest1 \
+-S \
+-M s390-ccw-virtio \
+-cpu zEC12,dfppc=on,stckf=off \
+-m 214 \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
+-nographic \
+-nodefaults \
+-monitor unix:/tmp/lib/domain--1-guest1/monitor.sock,server,nowait \
+-no-acpi \
+-boot c
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-features.xml 
b/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-features.xml
new file mode 100644
index 000..47279c4
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-features.xml
@@ -0,0 +1,23 @@
+
+  guest1
+  c7a5fdbd-edaf-9455-926a-d65c16db1809
+  219100
+  219100
+  1
+  
+hvm
+  
+  
+  destroy
+  restart
+  destroy
+  
+zEC12
+
+
+  
+  
+  /usr/bin/qemu-kvm
+  
+  
+
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index bd2cdcb..7579c6d 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -1522,6 +1522,8 @@ mymain(void)
 
 qemuTestSetHostArch(driver.caps, VIR_ARCH_S390X);
 DO_TEST("cpu-s390-zEC12", QEMU_CAPS_KVM, QEMU_CAPS_VIRTIO_CCW, 
QEMU_CAPS_VIRTIO_S390);
+DO_TEST("cpu-s390-features", QEMU_CAPS_KVM, 
QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION);
+DO_TEST_FAILURE("cpu-s390-features", QEMU_CAPS_KVM);
 qemuTestSetHostArch(driver.caps, VIR_ARCH_NONE);
 
 qemuTestSetHostCPU(driver.caps, cpuHaswell);
-- 
2.7.4

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

[libvirt] [PATCH 8/9] tests: qemuxml2argv s390x cpu model

[Jason J. Herne]

Test cases for qemu s390x cpu model argument generation.

Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 .../qemuxml2argv-cpu-s390-zEC12.args| 19 +++
 .../qemuxml2argv-cpu-s390-zEC12.xml | 21 +
 tests/qemuxml2argvtest.c| 12 
 3 files changed, 52 insertions(+)
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.xml

diff --git a/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.args 
b/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.args
new file mode 100644
index 000..4c95d6a
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.args
@@ -0,0 +1,19 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-kvm \
+-name guest1 \
+-S \
+-M s390-ccw-virtio \
+-cpu zEC12 \
+-m 214 \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
+-nographic \
+-nodefaults \
+-monitor unix:/tmp/lib/domain--1-guest1/monitor.sock,server,nowait \
+-no-acpi \
+-boot c
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.xml 
b/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.xml
new file mode 100644
index 000..de55f22
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.xml
@@ -0,0 +1,21 @@
+
+  guest1
+  c7a5fdbd-edaf-9455-926a-d65c16db1809
+  219100
+  219100
+  1
+  
+hvm
+  
+  
+  destroy
+  restart
+  destroy
+  
+zEC12
+  
+  
+  /usr/bin/qemu-kvm
+  
+  
+
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 81c62ac..bd2cdcb 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -300,6 +300,9 @@ testAddCPUModels(virQEMUCapsPtr caps, bool skipLegacy)
 const char *ppc64Models[] = {
 "POWER8", "POWER7",
 };
+const char *s390xModels[] = {
+"z990", "zEC12", "z13",
+};
 
 if (ARCH_IS_X86(arch)) {
 if (virQEMUCapsAddCPUDefinitions(caps, VIR_DOMAIN_VIRT_KVM, x86Models,
@@ -337,6 +340,11 @@ testAddCPUModels(virQEMUCapsPtr caps, bool skipLegacy)
  ARRAY_CARDINALITY(ppc64Models),
  VIR_DOMCAPS_CPU_USABLE_UNKNOWN) < 0)
 return -1;
+} else if (ARCH_IS_S390(arch)) {
+if (virQEMUCapsAddCPUDefinitions(caps, VIR_DOMAIN_VIRT_KVM, 
s390xModels,
+ ARRAY_CARDINALITY(s390xModels),
+ VIR_DOMCAPS_CPU_USABLE_UNKNOWN) < 0)
+return -1;
 }
 
 return 0;
@@ -1512,6 +1520,10 @@ mymain(void)
 DO_TEST_FAILURE("cpu-host-passthrough", NONE);
 DO_TEST_FAILURE("cpu-qemu-host-passthrough", QEMU_CAPS_KVM);
 
+qemuTestSetHostArch(driver.caps, VIR_ARCH_S390X);
+DO_TEST("cpu-s390-zEC12", QEMU_CAPS_KVM, QEMU_CAPS_VIRTIO_CCW, 
QEMU_CAPS_VIRTIO_S390);
+qemuTestSetHostArch(driver.caps, VIR_ARCH_NONE);
+
 qemuTestSetHostCPU(driver.caps, cpuHaswell);
 DO_TEST("cpu-Haswell", QEMU_CAPS_KVM);
 DO_TEST("cpu-Haswell2", QEMU_CAPS_KVM);
-- 
2.7.4

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

[libvirt] [PATCH 7/9] qemu-caps: Get host model directly from Qemu when available

[Jason J. Herne]

When qmp query-cpu-model-expansion is available probe Qemu for its view of the
host model. In kvm environments this can provide a more complete view of the
host model because features supported by Qemu and Kvm can be considered.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>

# Conflicts:
#   tests/qemucapabilitiesdata/caps_2.8.0.s390x.replies

Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/qemu/qemu_capabilities.c   | 185 -
 tests/domaincapsschemadata/qemu_2.7.0.s390x.xml|   4 +-
 tests/domaincapsschemadata/qemu_2.8.0.s390x.xml|  17 +-
 .../qemucapabilitiesdata/caps_2.8.0.s390x.replies  |  26 +++
 tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml|  17 ++
 5 files changed, 239 insertions(+), 10 deletions(-)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index bff30ed..7d33b19 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -399,6 +399,8 @@ struct _virQEMUCaps {
 size_t ngicCapabilities;
 virGICCapability *gicCapabilities;
 
+qemuMonitorCPUModelInfoPtr hostCPUModelInfo;
+
 /* Anything below is not stored in the cache since the values are
  * re-computed from the other fields or external data sources every
  * time we probe QEMU or load the results from the cache.
@@ -2163,6 +2165,10 @@ virQEMUCapsPtr virQEMUCapsNewCopy(virQEMUCapsPtr 
qemuCaps)
 !(ret->hostCPUModel = virCPUDefCopy(qemuCaps->hostCPUModel)))
 goto error;
 
+if (qemuCaps->hostCPUModelInfo &&
+!(ret->hostCPUModelInfo = 
qemuMonitorCPUModelInfoCopy(qemuCaps->hostCPUModelInfo)))
+goto error;
+
 if (VIR_ALLOC_N(ret->machineTypes, qemuCaps->nmachineTypes) < 0)
 goto error;
 ret->nmachineTypes = qemuCaps->nmachineTypes;
@@ -2811,6 +2817,18 @@ virQEMUCapsProbeQMPCPUDefinitions(virQEMUCapsPtr 
qemuCaps,
 return ret;
 }
 
+static int
+virQEMUCapsProbeQMPHostCPU(virQEMUCapsPtr qemuCaps,
+   qemuMonitorPtr mon)
+{
+if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION) ||
+!virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
+return 0;
+
+return qemuMonitorGetCPUModelExpansion(mon, "static", "host",
+   >hostCPUModelInfo);
+}
+
 struct tpmTypeToCaps {
 int type;
 virQEMUCapsFlags caps;
@@ -3020,18 +3038,62 @@ virQEMUCapsCPUFilterFeatures(const char *name,
 }
 
 
-void
-virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
-virCapsPtr caps)
+static void
+virQEMUCapsCopyCPUModelFromQEMU(virQEMUCapsPtr qemuCaps)
 {
 virCPUDefPtr cpu = NULL;
+qemuMonitorCPUModelInfoPtr modelInfo = NULL;
+size_t i;
 
-if (!caps)
-return;
+if (!(modelInfo = qemuCaps->hostCPUModelInfo)) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+   _("missing host CPU model info from QEMU capabilities"
+ " for binary %s"), qemuCaps->binary);
+goto error;
+}
 
-if (!virQEMUCapsGuestIsNative(caps->host.arch, qemuCaps->arch))
+if (VIR_ALLOC(cpu) < 0)
 goto error;
 
+if (VIR_STRDUP(cpu->model, modelInfo->name) < 0 ||
+VIR_ALLOC_N(cpu->features, modelInfo->nprops) < 0)
+goto error;
+
+cpu->nfeatures_max = modelInfo->nprops;
+cpu->nfeatures = 0;
+cpu->sockets = cpu->cores = cpu->threads = 0;
+cpu->type = VIR_CPU_TYPE_GUEST;
+cpu->mode = VIR_CPU_MODE_CUSTOM;
+cpu->match = VIR_CPU_MATCH_EXACT;
+
+for (i = 0; i < modelInfo->nprops; i++) {
+if (VIR_STRDUP(cpu->features[i].name, modelInfo->props[i].name) < 0)
+goto error;
+
+if (modelInfo->props[i].supported)
+cpu->features[i].policy = VIR_CPU_FEATURE_REQUIRE;
+else
+cpu->features[i].policy = VIR_CPU_FEATURE_DISABLE;
+
+cpu->nfeatures++;
+}
+
+qemuCaps->hostCPUModel = cpu;
+return;
+
+ error:
+virCPUDefFree(cpu);
+qemuCaps->hostCPUModel = NULL;
+virResetLastError();
+}
+
+
+static void
+virQEMUCapsCopyCPUModelFromHost(virQEMUCapsPtr qemuCaps,
+virCapsPtr caps)
+{
+virCPUDefPtr cpu = NULL;
+
 if (caps->host.cpu && caps->host.cpu->model) {
 if (VIR_ALLOC(cpu) < 0)
 goto error;
@@ -3055,6 +3117,98 @@ virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
 virResetLastError();
 }
 
+void
+virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
+virCapsPtr caps)
+{
+if (!caps || !virQEMUCapsGuestIsNative(caps->host.arch, qemuCaps->arch))
+return;
+
+switch (qemuCap

[libvirt] [PATCH 6/9] qemu: qmp query-cpu-model-expansion command

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

query-cpu-model-expansion is used to get a list of features for a given cpu
model name or to get the model and features of the host hardware/environment
as seen by Qemu/kvm.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/qemu/qemu_capabilities.c|   5 +-
 src/qemu/qemu_capabilities.h|   3 +
 src/qemu/qemu_monitor.c |  62 +
 src/qemu/qemu_monitor.h |  22 +
 src/qemu/qemu_monitor_json.c| 117 
 src/qemu/qemu_monitor_json.h|   6 ++
 tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml |   1 +
 7 files changed, 215 insertions(+), 1 deletion(-)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index f4ca84e..bff30ed 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -354,6 +354,8 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
   "gluster.debug_level",
   "vhost-scsi",
   "drive-iotune-group",
+
+  "query-cpu-model-expansion", /* 245 */
 );
 
 
@@ -1514,7 +1516,8 @@ struct virQEMUCapsStringFlags virQEMUCapsCommands[] = {
 { "rtc-reset-reinjection", QEMU_CAPS_RTC_RESET_REINJECTION },
 { "migrate-incoming", QEMU_CAPS_INCOMING_DEFER },
 { "query-hotpluggable-cpus", QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS },
-{ "query-qmp-schema", QEMU_CAPS_QUERY_QMP_SCHEMA }
+{ "query-qmp-schema", QEMU_CAPS_QUERY_QMP_SCHEMA },
+{ "query-cpu-model-expansion", QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION},
 };
 
 struct virQEMUCapsStringFlags virQEMUCapsMigration[] = {
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index cbab879..b5ad95e 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -390,6 +390,9 @@ typedef enum {
 QEMU_CAPS_DEVICE_VHOST_SCSI, /* -device vhost-scsi-{ccw,pci} */
 QEMU_CAPS_DRIVE_IOTUNE_GROUP, /* -drive throttling.group= */
 
+/* 245 */
+QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION, /* qmp query-cpu-model-expansion */
+
 QEMU_CAPS_LAST /* this must always be the last item */
 } virQEMUCapsFlags;
 
diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index 648168d..3a7ae0c 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -3660,6 +3660,68 @@ qemuMonitorCPUDefInfoFree(qemuMonitorCPUDefInfoPtr cpu)
 
 
 int
+qemuMonitorGetCPUModelExpansion(qemuMonitorPtr mon,
+const char *type,
+const char *model_name,
+qemuMonitorCPUModelInfoPtr *model_info)
+{
+VIR_DEBUG("type=%s model_name=%s", type, model_name);
+
+QEMU_CHECK_MONITOR_JSON(mon);
+
+return qemuMonitorJSONGetCPUModelExpansion(mon, type, model_name, 
model_info);
+}
+
+
+void
+qemuMonitorCPUModelInfoFree(qemuMonitorCPUModelInfoPtr model_info)
+{
+size_t i;
+
+if (!model_info)
+return;
+
+for (i = 0; i < model_info->nprops; i++)
+VIR_FREE(model_info->props[i].name);
+
+VIR_FREE(model_info->name);
+VIR_FREE(model_info);
+}
+
+
+qemuMonitorCPUModelInfoPtr
+qemuMonitorCPUModelInfoCopy(const qemuMonitorCPUModelInfo *orig)
+{
+qemuMonitorCPUModelInfoPtr copy;
+size_t i;
+
+if (VIR_ALLOC(copy) < 0)
+goto error;
+
+if (VIR_ALLOC_N(copy->props, orig->nprops) < 0)
+goto error;
+
+if (VIR_STRDUP(copy->name, orig->name) < 0)
+goto error;
+
+copy->nprops = orig->nprops;
+
+for (i = 0; i < orig->nprops; i++) {
+if (VIR_STRDUP(copy->props[i].name, orig->props[i].name) < 0)
+goto error;
+
+copy->props[i].supported = orig->props[i].supported;
+}
+
+return copy;
+
+ error:
+qemuMonitorCPUModelInfoFree(copy);
+return NULL;
+}
+
+
+int
 qemuMonitorGetCommands(qemuMonitorPtr mon,
char ***commands)
 {
diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h
index 4d7fb9f..c36c3ea 100644
--- a/src/qemu/qemu_monitor.h
+++ b/src/qemu/qemu_monitor.h
@@ -925,6 +925,28 @@ int qemuMonitorGetCPUDefinitions(qemuMonitorPtr mon,
  qemuMonitorCPUDefInfoPtr **cpus);
 void qemuMonitorCPUDefInfoFree(qemuMonitorCPUDefInfoPtr cpu);
 
+typedef struct _qemuMonitorCPUModelInfo qemuMonitorCPUModelInfo;
+typedef qemuMonitorCPUModelInfo *qemuMonitorCPUModelInfoPtr;
+
+struct _qemuMonitorCPUModelInfo {
+char *name;
+size_t nprops;
+struct {
+char *name;
+bool supported;
+} *props;
+};
+
+int qemuMonitorGetCPUModelExpansion(qemuMonitorPtr mon,
+  

[libvirt] [PATCH 2/9] s390-cpu: Remove nodeData and decode

[Jason J. Herne]

On s390, the host's features are heavily influenced by not only the host
hardware but also by hardware microcode level, host OS version, qemu
version and kvm version. In this environment it does not make sense to
attempt to report exact host details.

Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
Acked-by: Jiri Denemark <jdene...@redhat.com>
---
 src/cpu/cpu_s390.c | 36 ++--
 1 file changed, 2 insertions(+), 34 deletions(-)

diff --git a/src/cpu/cpu_s390.c b/src/cpu/cpu_s390.c
index bdc9ab5..d1670a9 100644
--- a/src/cpu/cpu_s390.c
+++ b/src/cpu/cpu_s390.c
@@ -33,38 +33,6 @@
 
 static const virArch archs[] = { VIR_ARCH_S390, VIR_ARCH_S390X };
 
-static virCPUDataPtr
-s390NodeData(virArch arch)
-{
-virCPUDataPtr data;
-
-if (VIR_ALLOC(data) < 0)
-return NULL;
-
-data->arch = arch;
-
-return data;
-}
-
-
-static int
-s390Decode(virCPUDefPtr cpu,
-   const virCPUData *data ATTRIBUTE_UNUSED,
-   const char **models ATTRIBUTE_UNUSED,
-   unsigned int nmodels ATTRIBUTE_UNUSED,
-   const char *preferred ATTRIBUTE_UNUSED,
-   unsigned int flags)
-{
-
-virCheckFlags(VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES, -1);
-
-if (cpu->model == NULL &&
-VIR_STRDUP(cpu->model, "host") < 0)
-return -1;
-
-return 0;
-}
-
 static void
 s390DataFree(virCPUDataPtr data)
 {
@@ -145,10 +113,10 @@ struct cpuArchDriver cpuDriverS390 = {
 .arch = archs,
 .narch = ARRAY_CARDINALITY(archs),
 .compare= virCPUs390Compare,
-.decode = s390Decode,
+.decode = NULL,
 .encode = NULL,
 .free   = s390DataFree,
-.nodeData   = s390NodeData,
+.nodeData   = NULL,
 .baseline   = NULL,
 .update = virCPUs390Update,
 };
-- 
2.7.4

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

[libvirt] [PATCH 0/9] Qemu: s390: Cpu Model Support

[Jason J. Herne]

This patch set enables cpu model support for s390. The user can now set exact
cpu models, query supported models via virsh domcapabilities, and use host-model
and host-passthrough modes. The end result is that migration is safer because
Qemu will perform runnability checking on the destination host and quit with an
error if the guest's cpu model is not supported.   

Note: Some test data has been separated from corresponding test case updates for
ease of review.

Changelog
-
[v3]

s390: Cpu driver support for update and compare
 - Fixed indentation of error message in  virCPUs390Update
 
test-data: Qemu caps replies and xml for s390x qemu 2.7 and 2.8
 - Moved this patch before introduction of query-cpu-model-expansion
 - Regenerated all test data

tests: domain capabilities: qemu 2.7 and 2.8 on s390x
 - Added Qemu 2.7 test
 - Removed fake host model name
 - Moved this patch before introduction of query-cpu-model-expansion

tests: qemu capabilites: qemu 2.7 and 2.8 on s390x
 - Moved this patch before introduction of query-cpu-model-expansion
 - Stop using fake host cpu
 
qemu: qmp query-cpu-model-expansion command
 - Moved query-cpu-model-expansion capability to this patch
 - changed label "cleanup" to "error" in qemuMonitorCPUModelInfoCopy
 - qemuMonitorJSONParseCPUModelProperty is now static, and also made
   appropriate changes when passing a boolean to virJSONValueGetBoolean
 - removed unnecessary error checking when assigning "data" variable in
   qemuMonitorJSONGetCPUModelExpansion 
 - Fix up capabilities test data to reflect changes from this commit
 - fixed query-cpu-model-expansion's enumeration formatting
 
qemu-caps: Get host model directly from Qemu when available
 - Moved query-cpu-model-expansion capability from this patch
 - virQEMUCapsCopyCPUModelFromQEMU is now static and type void
 - check for native guest is done before attempting to set host CPU
 - s390x no longer falls back to getting host CPU model from the host
   if it cannot be retrieved from QEMU
 - fixed unnecessary intialization of some variables that were introduced
   in v2 of these patches
 - virQEMUCapsLoadHostCPUModelInfo now first allocates data into a
   qemuMonitorCPUModelInfoPtr before assigning it to appropriate qemuCaps field
 - if we do not have QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION available, skip
   trying to read the hostCPU portion of the qemu cache file
 - all hostCPU element parsing is handled in its entirety within function
   virQEMUCapsLoadHostCPUModelInfo
 - Fix up capabilities test data to reflect changes from this commit

qemu: command: Support new cpu feature argument syntax
 - Add error message for case where s390 guest attempts to use cpu features on
   older qemu.
 - Combined the tests into this commit
 - Now tests s390 cpu features both with and without query-cpu-model-expansion

[v2]
* Added s390x cpu and capabilities tests
* Added cpu feature syntax tests
* Dropped patch: Warn when migrating host-passthrough
* Added patch: Document migrating host-passthrough is dangerous

s390: Cpu driver support for update and compare
 - Compare: Added comment explaining why s390 bypasses the cpuCompare operation
 - Update: Added error message explaining minimum match mode is not supported
 - Update: Ensure user is not using unsupported optional feature policy
 - Update: Use virCPUDefUpdateFeature to update/create user requested features
 - Other minor fixes
 
s390-cpu: Remove nodeData and decode
 - Completely remove nodeData and decode functions

qemu: qmp query-cpu-model-expansion command
 - Cleaned up debug print
 - Restructured qemuMonitorJSONGetCPUModelExpansion
 - Added more JSON parsing error handling
 - CPU model features now parsed via an iterator
 - qemuMonitorJSONGetCPUModelExpansion: Fixed double free of model ptr
 - Restructure qemuMonitorCPUModelInfoFree
 - Other minor fixes

qemu-caps: Get host model directly from Qemu when available
 - virQEMUCapsProbeQMPHostCPU: indentation fix
 - Fixed rebase error involving a missing 'goto cleanup;'.
 - Fix indentation in virQEMUCapsProbeQMPHostCPU
 - virQEMUCapsInitHostCPUModel now routes to virQEMUCapsCopyModelFromQEMU or
   virQEMUCapsCopyModelFromHost, depending on architecture.
 - Restructure hostCpu data in qemu caps cache xml
 - Other minor fixes

Collin L. Walling (5):
  test-data: Qemu caps replies and xml for s390x qemu 2.7 and 2.8
  tests: domain capabilities: qemu 2.7 and 2.8 on s390x
  tests: qemu capabilites: qemu 2.7 and 2.8 on s390x
  qemu: qmp query-cpu-model-expansion command
  qemu: command: Support new cpu feature argument syntax

Jason J. Herne (4):
  s390: Cpu driver support for update and compare
  s390-cpu: Remove nodeData and decode
  qemu-caps: Get host model directly from Qemu when available
  tests: qemuxml2argv s390x cpu model

 po/POTFILES.in | 1 +
 src/cpu/cpu_s390.c |   103 +-
 src/qemu/qemu_capabilities.c 

[libvirt] [PATCH 1/9] s390: Cpu driver support for update and compare

[Jason J. Herne]

Implement compare for s390. Required to test the guest against the host for
guest cpu model runnability checking. We always return IDENTICAL to bypass
Libvirt's checking. s390 will rely on Qemu to perform the runnability checking.

Implement update for s390. required to support use of cpu "host-model" mode.

Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
Acked-by: Jiri Denemark <jdene...@redhat.com>
---
 po/POTFILES.in |  1 +
 src/cpu/cpu_s390.c | 73 --
 2 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/po/POTFILES.in b/po/POTFILES.in
index e66bb7a..59efd91 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -46,6 +46,7 @@ src/cpu/cpu.c
 src/cpu/cpu_arm.c
 src/cpu/cpu_map.c
 src/cpu/cpu_ppc64.c
+src/cpu/cpu_s390.c
 src/cpu/cpu_x86.c
 src/datatypes.c
 src/driver.c
diff --git a/src/cpu/cpu_s390.c b/src/cpu/cpu_s390.c
index 04a6bea..bdc9ab5 100644
--- a/src/cpu/cpu_s390.c
+++ b/src/cpu/cpu_s390.c
@@ -71,15 +71,84 @@ s390DataFree(virCPUDataPtr data)
 VIR_FREE(data);
 }
 
+static virCPUCompareResult
+virCPUs390Compare(virCPUDefPtr host ATTRIBUTE_UNUSED,
+  virCPUDefPtr cpu ATTRIBUTE_UNUSED,
+  bool failMessages ATTRIBUTE_UNUSED)
+{
+/* s390 relies on Qemu to perform all runability checking. Return
+ * VIR_CPU_COMPARE_IDENTICAL to bypass Libvirt checking.
+ */
+return VIR_CPU_COMPARE_IDENTICAL;
+}
+
+static int
+virCPUs390Update(virCPUDefPtr guest,
+ const virCPUDef *host)
+{
+ virCPUDefPtr updated = NULL;
+ int ret = -1;
+ size_t i;
+
+ if (guest->match == VIR_CPU_MATCH_MINIMUM) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+_("match mode %s not supported"),
+virCPUMatchTypeToString(guest->match));
+ goto cleanup;
+ }
+
+ if (guest->mode != VIR_CPU_MODE_HOST_MODEL) {
+ ret = 0;
+ goto cleanup;
+ }
+
+ if (!host) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+_("unknown host CPU model"));
+ goto cleanup;
+ }
+
+ if (!(updated = virCPUDefCopyWithoutModel(guest)))
+ goto cleanup;
+
+ updated->mode = VIR_CPU_MODE_CUSTOM;
+ if (virCPUDefCopyModel(updated, host, true) < 0)
+ goto cleanup;
+
+ for (i = 0; i < guest->nfeatures; i++) {
+ if (guest->features[i].policy == VIR_CPU_FEATURE_OPTIONAL) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+_("only cpu feature policies 'require' and "
+"'disable' are supported for %s"),
+guest->features[i].name);
+ goto cleanup;
+}
+
+if (virCPUDefUpdateFeature(updated,
+   guest->features[i].name,
+   guest->features[i].policy) < 0)
+goto cleanup;
+ }
+
+ virCPUDefStealModel(guest, updated, false);
+ guest->mode = VIR_CPU_MODE_CUSTOM;
+ guest->match = VIR_CPU_MATCH_EXACT;
+ ret = 0;
+
+ cleanup:
+ virCPUDefFree(updated);
+ return ret;
+}
+
 struct cpuArchDriver cpuDriverS390 = {
 .name = "s390",
 .arch = archs,
 .narch = ARRAY_CARDINALITY(archs),
-.compare= NULL,
+.compare= virCPUs390Compare,
 .decode = s390Decode,
 .encode = NULL,
 .free   = s390DataFree,
 .nodeData   = s390NodeData,
 .baseline   = NULL,
-.update = NULL,
+.update = virCPUs390Update,
 };
-- 
2.7.4

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

[libvirt] [PATCH 4/9] tests: domain capabilities: qemu 2.7 and 2.8 on s390x

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

Tests domain capabilities on s390x using the Qemu 2.8 capabilities data.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 tests/domaincapsschemadata/qemu_2.7.0.s390x.xml |  80 +
 tests/domaincapsschemadata/qemu_2.8.0.s390x.xml | 144 
 tests/domaincapstest.c  |  18 +++
 3 files changed, 242 insertions(+)
 create mode 100644 tests/domaincapsschemadata/qemu_2.7.0.s390x.xml
 create mode 100644 tests/domaincapsschemadata/qemu_2.8.0.s390x.xml

diff --git a/tests/domaincapsschemadata/qemu_2.7.0.s390x.xml 
b/tests/domaincapsschemadata/qemu_2.7.0.s390x.xml
new file mode 100644
index 000..9f181d3
--- /dev/null
+++ b/tests/domaincapsschemadata/qemu_2.7.0.s390x.xml
@@ -0,0 +1,80 @@
+
+  /usr/bin/qemu-system-s390x
+  kvm
+  s390-ccw-virtio-2.7
+  s390x
+  
+  
+
+  /usr/share/AAVMF/AAVMF_CODE.fd
+  /usr/share/OVMF/OVMF_CODE.fd
+  
+rom
+pflash
+  
+  
+yes
+no
+  
+
+  
+  
+
+
+  
+
+
+  
+  
+
+  
+disk
+cdrom
+floppy
+lun
+  
+  
+ide
+fdc
+scsi
+virtio
+  
+
+
+  
+sdl
+vnc
+  
+
+
+  
+virtio
+  
+
+
+  
+subsystem
+  
+  
+default
+mandatory
+requisite
+optional
+  
+  
+usb
+pci
+scsi
+  
+  
+  
+default
+kvm
+vfio
+  
+
+  
+  
+
+  
+
diff --git a/tests/domaincapsschemadata/qemu_2.8.0.s390x.xml 
b/tests/domaincapsschemadata/qemu_2.8.0.s390x.xml
new file mode 100644
index 000..0b792b2
--- /dev/null
+++ b/tests/domaincapsschemadata/qemu_2.8.0.s390x.xml
@@ -0,0 +1,144 @@
+
+  /usr/bin/qemu-system-s390x
+  kvm
+  s390-ccw-virtio-2.8
+  s390x
+  
+  
+
+  /usr/share/AAVMF/AAVMF_CODE.fd
+  /usr/share/OVMF/OVMF_CODE.fd
+  
+rom
+pflash
+  
+  
+yes
+no
+  
+
+  
+  
+
+
+  
+
+
+  z10EC-base
+  z9EC-base
+  z196.2-base
+  z900-base
+  z990
+  z900.2-base
+  z900.3
+  z114
+  z890-base
+  z13.2-base
+  zEC12.2
+  z900.2
+  z10BC
+  z10BC.2
+  z196
+  z9EC
+  z990-base
+  z10EC.3
+  z900
+  z9EC.3-base
+  z990.5-base
+  z10EC.2
+  z9BC.2
+  z10EC
+  z990.3-base
+  z13s
+  z10EC.3-base
+  zEC12.2-base
+  z890.3-base
+  z9EC.3
+  z990.5
+  z13
+  z13s-base
+  z9EC.2
+  z990.4
+  zEC12-base
+  z9EC.2-base
+  zBC12
+  z196.2
+  z990.3
+  z990.2-base
+  z900.3-base
+  z890.3
+  z10EC.2-base
+  z990.2
+  z890.2
+  zBC12-base
+  z800-base
+  zEC12
+  z9BC.2-base
+  z9BC
+  z10BC.2-base
+  z990.4-base
+  qemu
+  z10BC-base
+  z9BC-base
+  z800
+  z890.2-base
+  z13.2
+  z114-base
+  z196-base
+  z13-base
+  z890
+
+  
+  
+
+  
+disk
+cdrom
+floppy
+lun
+  
+  
+ide
+fdc
+scsi
+virtio
+  
+
+
+  
+sdl
+vnc
+  
+
+
+  
+virtio
+  
+
+
+  
+subsystem
+  
+  
+default
+mandatory
+requisite
+optional
+  
+  
+usb
+pci
+scsi
+  
+  
+  
+default
+kvm
+vfio
+  
+
+  
+  
+
+  
+
diff --git a/tests/domaincapstest.c b/tests/domaincapstest.c
index fea5120..6b8bd2e 100644
--- a/tests/domaincapstest.c
+++ b/tests/domaincapstest.c
@@ -134,6 +134,12 @@ static virCPUDef x86Cpu = {
 NULL, 0, NULL, 1, 1, 1, 0, 0, NULL,
 };
 
+static virCPUDef s390Cpu = {
+VIR_CPU_TYPE_HOST, 0, 0,
+VIR_ARCH_S390X, (char *) "",
+NULL, 0, NULL, 1, 1, 1, 0, 0, NULL,
+};
+
 static int
 fakeHostCPU(virCapsPtr caps,
 virArch arch)
@@ -153,6 +159,10 @@ fakeHostCPU(virCapsPtr caps,
 cpu = 
 break;
 
+case VIR_ARCH_S390X:
+cpu = 
+break;
+
 default:
 virReportError(VIR_ERR_INTERNAL_ERROR,
"cannot fake host CPU for arch %s",
@@ -443,6 +453,14 @@ mymain(void)
  "/usr/bin/qemu-system-x86_64", NULL,
  "x86_64", VIR_DOMAIN_VIRT_QEMU);
 
+DO_TEST_QEMU("2.7.0", "caps_2.7.0",
+ "/usr/bin/qemu-system-s390x", NULL,
+ "s390x", VIR_DOMAIN_VIRT_KVM);
+
+DO_TEST_QEMU("2.8.0", "caps_2.8.0",
+ "/usr

Re: [libvirt] [PATCH v2 00/11] Qemu: s390: Cpu Model Support

[Jason J. Herne]

On 12/15/2016 11:55 AM, Jiri Denemark wrote:

On Fri, Dec 09, 2016 at 14:38:29 -0500, Jason J. Herne wrote:

This patch set enables cpu model support for s390. The user can now set exact
cpu models, query supported models via virsh domcapabilities, and use host-model
and host-passthrough modes. The end result is that migration is safer because
Qemu will perform runnability checking on the destination host and quit with an
error if the guest's cpu model is not supported.


A slightly (un)related question: is QEMU going to implement
unavailable-features for s390? In other words, will libvirt users be
able to easily see what CPU models can be used on a host? The libvirt
code should be ready so it's just a matter of making QEMU report
unavailable-features.

Jirka



If so, it will likely be after this set of patches. Sounds like good follow
on work.

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] [PATCH v2 06/11] docs: document cpu host-passthrough migration issue

[Jason J. Herne]

On 12/15/2016 11:18 AM, Jiri Denemark wrote:

On Fri, Dec 09, 2016 at 14:38:35 -0500, Jason J. Herne wrote:

Documents in formatdomain.html that when migrating a guest
defined with the host-passthrough CPU model from a machine that
is running on a newer CPU model than the destination machine's
CPU model, it is very likely that the guest will crash upon
arrival.

Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 docs/formatdomain.html.in | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 9218eec..b7c1e87 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1292,7 +1292,11 @@
   understand. Though the downside of this mode is that the guest
   environment cannot be reproduced on different hardware. Thus, if you
   hit any bugs, you are on your own. Further details of that CPU can
-  be changed using feature elements.
+  be changed using feature elements. Migration of a guest
+  using host-passthrough is dangerous if the source and destination
+  hosts are not identical in both hardware and configuration. If such
+  a migration is attempted then the guest will very likely hang or
+  crash upon resuming execution on the destination host.
 


I'd say "may" rather than "will very likely" :-) The likelihood of such
behavior depends on a lot of factors, such as the host architecture, the
way the hosts differ, etc. For example, on x86_64 such migration will
work just fine as long as the destination host is not worse than the
source host and even if it is, it depends on what the guest is doing.

ACK and it can be pushed right away, just let me know whether you agree
with the suggested change.

Jirka



Hi Jiri,

Thanks for reviewing. Yes, we agree with your change to this. Let me 
know if you push it and we'll remove it from this series.


--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

[libvirt] [PATCH v2 11/11] tests: domain capabilities: qemu 2.8 on s390x

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

Tests the domain capabilities on s390x using the Qemu 2.8 capabilities data.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 tests/domaincapsschemadata/qemu_2.8.0.s390x.xml | 159 
 tests/domaincapstest.c  |  14 +++
 2 files changed, 173 insertions(+)
 create mode 100644 tests/domaincapsschemadata/qemu_2.8.0.s390x.xml

diff --git a/tests/domaincapsschemadata/qemu_2.8.0.s390x.xml 
b/tests/domaincapsschemadata/qemu_2.8.0.s390x.xml
new file mode 100644
index 000..efe3459
--- /dev/null
+++ b/tests/domaincapsschemadata/qemu_2.8.0.s390x.xml
@@ -0,0 +1,159 @@
+
+  /usr/bin/qemu-system-s390x
+  kvm
+  s390-ccw-virtio-2.8
+  s390x
+  
+  
+
+  /usr/share/AAVMF/AAVMF_CODE.fd
+  /usr/share/OVMF/OVMF_CODE.fd
+  
+rom
+pflash
+  
+  
+yes
+no
+  
+
+  
+  
+
+
+  zEC12.2-base
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
+
+  z10EC-base
+  z9EC-base
+  z196.2-base
+  z900-base
+  z990
+  z900.2-base
+  z900.3
+  z114
+  z890-base
+  z13.2-base
+  zEC12.2
+  z900.2
+  z10BC
+  z10BC.2
+  z196
+  z9EC
+  z990-base
+  z10EC.3
+  z900
+  z9EC.3-base
+  z990.5-base
+  z10EC.2
+  z9BC.2
+  z10EC
+  z990.3-base
+  z13s
+  z10EC.3-base
+  zEC12.2-base
+  z890.3-base
+  z9EC.3
+  z990.5
+  z13
+  z13s-base
+  z9EC.2
+  z990.4
+  zEC12-base
+  z9EC.2-base
+  zBC12
+  z196.2
+  z990.3
+  z990.2-base
+  z900.3-base
+  z890.3
+  z10EC.2-base
+  z990.2
+  z890.2
+  zBC12-base
+  z800-base
+  zEC12
+  z9BC.2-base
+  z9BC
+  z10BC.2-base
+  z990.4-base
+  qemu
+  z10BC-base
+  z9BC-base
+  z800
+  z890.2-base
+  z13.2
+  z114-base
+  z196-base
+  z13-base
+  z890
+
+  
+  
+
+  
+disk
+cdrom
+floppy
+lun
+  
+  
+ide
+fdc
+scsi
+virtio
+  
+
+
+  
+sdl
+vnc
+  
+
+
+  
+virtio
+  
+
+
+  
+subsystem
+  
+  
+default
+mandatory
+requisite
+optional
+  
+  
+usb
+pci
+scsi
+  
+  
+  
+default
+kvm
+vfio
+  
+
+  
+  
+
+  
+
diff --git a/tests/domaincapstest.c b/tests/domaincapstest.c
index fea5120..9ba26db 100644
--- a/tests/domaincapstest.c
+++ b/tests/domaincapstest.c
@@ -134,6 +134,12 @@ static virCPUDef x86Cpu = {
 NULL, 0, NULL, 1, 1, 1, 0, 0, NULL,
 };
 
+static virCPUDef s390Cpu = {
+VIR_CPU_TYPE_HOST, 0, 0,
+VIR_ARCH_S390X, (char *) "zEC12.2-base",
+NULL, 0, NULL, 1, 1, 1, 0, 0, NULL,
+};
+
 static int
 fakeHostCPU(virCapsPtr caps,
 virArch arch)
@@ -153,6 +159,10 @@ fakeHostCPU(virCapsPtr caps,
 cpu = 
 break;
 
+case VIR_ARCH_S390X:
+cpu = 
+break;
+
 default:
 virReportError(VIR_ERR_INTERNAL_ERROR,
"cannot fake host CPU for arch %s",
@@ -443,6 +453,10 @@ mymain(void)
  "/usr/bin/qemu-system-x86_64", NULL,
  "x86_64", VIR_DOMAIN_VIRT_QEMU);
 
+DO_TEST_QEMU("2.8.0", "caps_2.8.0",
+ "/usr/bin/qemu-system-s390x", NULL,
+ "s390x", VIR_DOMAIN_VIRT_KVM);
+
 #endif /* WITH_QEMU */
 
 #if WITH_LIBXL
-- 
2.7.4

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

[libvirt] [PATCH v2 10/11] tests: qemu capabilites: qemu 2.7 and 2.8 on s390x

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

Tests Qemu capabilities on s390x before and after the availability of
the query-cpu-model-expansion QMP command. The host CPU is mocked to use
the zEC12.2-base model for these tests, which has a defined set of features
expected to be available on this model.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 tests/qemucapabilitiestest.c |  4 
 tests/testutilsqemu.c| 39 ++-
 tests/testutilsqemu.h|  1 +
 3 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/tests/qemucapabilitiestest.c b/tests/qemucapabilitiestest.c
index 51d0cc4..1214d7c 100644
--- a/tests/qemucapabilitiestest.c
+++ b/tests/qemucapabilitiestest.c
@@ -172,6 +172,10 @@ mymain(void)
 DO_TEST("aarch64", "caps_2.6.0-gicv2");
 DO_TEST("aarch64", "caps_2.6.0-gicv3");
 DO_TEST("ppc64le", "caps_2.6.0");
+qemuTestSetHostCPU(driver.caps, cpuS390zEC12_2_base);
+DO_TEST("s390x", "caps_2.7.0");
+DO_TEST("s390x", "caps_2.8.0");
+qemuTestSetHostCPU(driver.caps, NULL);
 
 /*
  * Run "tests/qemucapsprobe /path/to/qemu/binary >foo.replies"
diff --git a/tests/testutilsqemu.c b/tests/testutilsqemu.c
index 56a89c9..a93987e 100644
--- a/tests/testutilsqemu.c
+++ b/tests/testutilsqemu.c
@@ -17,6 +17,7 @@
 virCPUDefPtr cpuDefault;
 virCPUDefPtr cpuHaswell;
 virCPUDefPtr cpuPower8;
+virCPUDefPtr cpuS390zEC12_2_base;
 
 static virCPUFeatureDef cpuDefaultFeatures[] = {
 { (char *) "ds",-1 },
@@ -93,6 +94,40 @@ static virCPUDef cpuHaswellData = {
 cpuHaswellFeatures, /* features */
 };
 
+static virCPUFeatureDef cpuS390zEC12_2_base_Features[] = {
+{ (char *) "aefsi", -1 },
+{ (char *) "msa5",  -1 },
+{ (char *) "msa4",  -1 },
+{ (char *) "msa3",  -1 },
+{ (char *) "msa2",  -1 },
+{ (char *) "msa1",  -1 },
+{ (char *) "sthyi", -1 },
+{ (char *) "edat",  -1 },
+{ (char *) "ri",-1 },
+{ (char *) "edat2", -1 },
+{ (char *) "ipter", -1 },
+{ (char *) "esop",  -1 },
+{ (char *) "cte",   -1 },
+{ (char *) "te",-1 },
+{ (char *) "cmm",   -1 },
+};
+static virCPUDef cpuS390zEC12_2_base_Data = {
+VIR_CPU_TYPE_HOST,  /* type */
+0,  /* mode */
+0,  /* match */
+VIR_ARCH_S390X, /* arch */
+(char *) "zEC12-base",  /* model */
+NULL,   /* vendor_id */
+0,  /* fallback */
+NULL,   /* vendor */
+1,  /* sockets */
+1,  /* cores */
+1,  /* threads */
+ARRAY_CARDINALITY(cpuS390zEC12_2_base_Features), /* nfeatures */
+ARRAY_CARDINALITY(cpuS390zEC12_2_base_Features), /* nfeatures_max */
+cpuS390zEC12_2_base_Features, /* features */
+};
+
 static virCPUDef cpuPower8Data = {
 .type = VIR_CPU_TYPE_HOST,
 .arch = VIR_ARCH_PPC64,
@@ -342,7 +377,8 @@ virCapsPtr testQemuCapsInit(void)
 
 if (!(cpuDefault = virCPUDefCopy()) ||
 !(cpuHaswell = virCPUDefCopy()) ||
-!(cpuPower8 = virCPUDefCopy()))
+!(cpuPower8 = virCPUDefCopy()) ||
+!(cpuS390zEC12_2_base = virCPUDefCopy(_2_base_Data)))
 goto cleanup;
 
 qemuTestSetHostCPU(caps, NULL);
@@ -455,6 +491,7 @@ virCapsPtr testQemuCapsInit(void)
 virCPUDefFree(cpuDefault);
 virCPUDefFree(cpuHaswell);
 virCPUDefFree(cpuPower8);
+virCPUDefFree(cpuS390zEC12_2_base);
 virObjectUnref(caps);
 return NULL;
 }
diff --git a/tests/testutilsqemu.h b/tests/testutilsqemu.h
index 047a64d..3c62466 100644
--- a/tests/testutilsqemu.h
+++ b/tests/testutilsqemu.h
@@ -21,6 +21,7 @@ virQEMUCapsPtr qemuTestParseCapabilities(virCapsPtr caps,
 extern virCPUDefPtr cpuDefault;
 extern virCPUDefPtr cpuHaswell;
 extern virCPUDefPtr cpuPower8;
+extern virCPUDefPtr cpuS390zEC12_2_base;
 
 void qemuTestSetHostArch(virCapsPtr caps,
 virArch arch);
-- 
2.7.4

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

[libvirt] [PATCH v2 04/11] qemu-caps: Get host model directly from Qemu when available

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

When qmp query-cpu-model-expansion is available probe Qemu for its view of the
host model. In kvm environments this can provide a more complete view of the
host model because features supported by Qemu and Kvm can be considered.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/qemu/qemu_capabilities.c | 180 ++-
 src/qemu/qemu_capabilities.h |   1 +
 2 files changed, 177 insertions(+), 4 deletions(-)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 081afc5..793afcc 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -354,6 +354,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
   "gluster.debug_level",
   "vhost-scsi",
   "drive-iotune-group",
+  "query-cpu-model-expansion",
 );
 
 
@@ -397,6 +398,8 @@ struct _virQEMUCaps {
 size_t ngicCapabilities;
 virGICCapability *gicCapabilities;
 
+qemuMonitorCPUModelInfoPtr hostCPUModelInfo;
+
 /* Anything below is not stored in the cache since the values are
  * re-computed from the other fields or external data sources every
  * time we probe QEMU or load the results from the cache.
@@ -1514,7 +1517,8 @@ struct virQEMUCapsStringFlags virQEMUCapsCommands[] = {
 { "rtc-reset-reinjection", QEMU_CAPS_RTC_RESET_REINJECTION },
 { "migrate-incoming", QEMU_CAPS_INCOMING_DEFER },
 { "query-hotpluggable-cpus", QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS },
-{ "query-qmp-schema", QEMU_CAPS_QUERY_QMP_SCHEMA }
+{ "query-qmp-schema", QEMU_CAPS_QUERY_QMP_SCHEMA },
+{ "query-cpu-model-expansion", QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION},
 };
 
 struct virQEMUCapsStringFlags virQEMUCapsMigration[] = {
@@ -2160,6 +2164,10 @@ virQEMUCapsPtr virQEMUCapsNewCopy(virQEMUCapsPtr 
qemuCaps)
 !(ret->hostCPUModel = virCPUDefCopy(qemuCaps->hostCPUModel)))
 goto error;
 
+if (qemuCaps->hostCPUModelInfo &&
+!(ret->hostCPUModelInfo = 
qemuMonitorCPUModelInfoCopy(qemuCaps->hostCPUModelInfo)))
+goto error;
+
 if (VIR_ALLOC_N(ret->machineTypes, qemuCaps->nmachineTypes) < 0)
 goto error;
 ret->nmachineTypes = qemuCaps->nmachineTypes;
@@ -2808,6 +2816,18 @@ virQEMUCapsProbeQMPCPUDefinitions(virQEMUCapsPtr 
qemuCaps,
 return ret;
 }
 
+static int
+virQEMUCapsProbeQMPHostCPU(virQEMUCapsPtr qemuCaps,
+   qemuMonitorPtr mon)
+{
+if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION) ||
+!virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
+return 0;
+
+return qemuMonitorGetCPUModelExpansion(mon, "static", "host",
+   >hostCPUModelInfo);
+}
+
 struct tpmTypeToCaps {
 int type;
 virQEMUCapsFlags caps;
@@ -3017,9 +3037,60 @@ virQEMUCapsCPUFilterFeatures(const char *name,
 }
 
 
-void
-virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
-virCapsPtr caps)
+static int
+virQEMUCapsCopyCPUModelFromQEMU(virQEMUCapsPtr qemuCaps)
+{
+virCPUDefPtr cpu = NULL;
+qemuMonitorCPUModelInfoPtr modelInfo = NULL;
+size_t i;
+
+if (!(modelInfo = qemuCaps->hostCPUModelInfo)) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+   _("missing host CPU model info from QEMU capabilities"
+ " for binary %s"), qemuCaps->binary);
+goto error;
+}
+
+if (VIR_ALLOC(cpu) < 0)
+goto error;
+
+if (VIR_STRDUP(cpu->model, modelInfo->name) < 0 ||
+VIR_ALLOC_N(cpu->features, modelInfo->nprops) < 0)
+goto error;
+
+cpu->nfeatures_max = modelInfo->nprops;
+cpu->nfeatures = 0;
+cpu->sockets = cpu->cores = cpu->threads = 0;
+cpu->type = VIR_CPU_TYPE_GUEST;
+cpu->mode = VIR_CPU_MODE_CUSTOM;
+cpu->match = VIR_CPU_MATCH_EXACT;
+
+for (i = 0; i < modelInfo->nprops; i++) {
+if (VIR_STRDUP(cpu->features[i].name, modelInfo->props[i].name) < 0)
+goto error;
+
+if (modelInfo->props[i].supported)
+cpu->features[i].policy = VIR_CPU_FEATURE_REQUIRE;
+else
+cpu->features[i].policy = VIR_CPU_FEATURE_DISABLE;
+
+cpu->nfeatures++;
+}
+
+qemuCaps->hostCPUModel = cpu;
+return 0;
+
+ error:
+virCPUDefFree(cpu);
+qemuCaps->hostCPUModel = NULL;
+virResetLastError();
+return -1;
+}
+
+
+static void
+virQEMUCapsCopyCPUModelFromHost(virQEMUCapsPtr qemuCaps,
+virCapsPtr caps)
 {
 virCPUDefPtr cpu = NULL;
 

[libvirt] [PATCH v2 03/11] qemu: qmp query-cpu-model-expansion command

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

query-cpu-model-expansion is used to get a list of features for a given cpu
model name or to get the model and features of the host hardware/environment
as seen by Qemu/kvm.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/qemu/qemu_monitor.c  |  62 ++
 src/qemu/qemu_monitor.h  |  22 
 src/qemu/qemu_monitor_json.c | 121 +++
 src/qemu/qemu_monitor_json.h |  12 +
 4 files changed, 217 insertions(+)

diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index 648168d..1a9665f 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -3660,6 +3660,68 @@ qemuMonitorCPUDefInfoFree(qemuMonitorCPUDefInfoPtr cpu)
 
 
 int
+qemuMonitorGetCPUModelExpansion(qemuMonitorPtr mon,
+const char *type,
+const char *model_name,
+qemuMonitorCPUModelInfoPtr *model_info)
+{
+VIR_DEBUG("type=%s model_name=%s", type, model_name);
+
+QEMU_CHECK_MONITOR_JSON(mon);
+
+return qemuMonitorJSONGetCPUModelExpansion(mon, type, model_name, 
model_info);
+}
+
+
+void
+qemuMonitorCPUModelInfoFree(qemuMonitorCPUModelInfoPtr model_info)
+{
+size_t i;
+
+if (!model_info)
+return;
+
+for (i = 0; i < model_info->nprops; i++)
+VIR_FREE(model_info->props[i].name);
+
+VIR_FREE(model_info->name);
+VIR_FREE(model_info);
+}
+
+
+qemuMonitorCPUModelInfoPtr
+qemuMonitorCPUModelInfoCopy(const qemuMonitorCPUModelInfo *orig)
+{
+qemuMonitorCPUModelInfoPtr copy;
+size_t i;
+
+if (VIR_ALLOC(copy) < 0)
+goto cleanup;
+
+if (VIR_ALLOC_N(copy->props, orig->nprops) < 0)
+goto cleanup;
+
+if (VIR_STRDUP(copy->name, orig->name) < 0)
+goto cleanup;
+
+copy->nprops = orig->nprops;
+
+for (i = 0; i < orig->nprops; i++) {
+if (VIR_STRDUP(copy->props[i].name, orig->props[i].name) < 0)
+goto cleanup;
+
+copy->props[i].supported = orig->props[i].supported;
+}
+
+return copy;
+
+ cleanup:
+qemuMonitorCPUModelInfoFree(copy);
+return NULL;
+}
+
+
+int
 qemuMonitorGetCommands(qemuMonitorPtr mon,
char ***commands)
 {
diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h
index 4d7fb9f..c36c3ea 100644
--- a/src/qemu/qemu_monitor.h
+++ b/src/qemu/qemu_monitor.h
@@ -925,6 +925,28 @@ int qemuMonitorGetCPUDefinitions(qemuMonitorPtr mon,
  qemuMonitorCPUDefInfoPtr **cpus);
 void qemuMonitorCPUDefInfoFree(qemuMonitorCPUDefInfoPtr cpu);
 
+typedef struct _qemuMonitorCPUModelInfo qemuMonitorCPUModelInfo;
+typedef qemuMonitorCPUModelInfo *qemuMonitorCPUModelInfoPtr;
+
+struct _qemuMonitorCPUModelInfo {
+char *name;
+size_t nprops;
+struct {
+char *name;
+bool supported;
+} *props;
+};
+
+int qemuMonitorGetCPUModelExpansion(qemuMonitorPtr mon,
+const char *type,
+const char *model_name,
+qemuMonitorCPUModelInfoPtr *model_info);
+
+void qemuMonitorCPUModelInfoFree(qemuMonitorCPUModelInfoPtr model_info);
+
+qemuMonitorCPUModelInfoPtr
+qemuMonitorCPUModelInfoCopy(const qemuMonitorCPUModelInfo *orig);
+
 int qemuMonitorGetCommands(qemuMonitorPtr mon,
char ***commands);
 int qemuMonitorGetEvents(qemuMonitorPtr mon,
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index 0c38b8f..9189a8b 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -4973,6 +4973,127 @@ qemuMonitorJSONGetCPUDefinitions(qemuMonitorPtr mon,
 return ret;
 }
 
+int
+qemuMonitorJSONParseCPUModelProperty(const char *key,
+ const virJSONValue *value,
+ void *opaque)
+{
+qemuMonitorCPUModelInfoPtr machine_model = opaque;
+size_t n = machine_model->nprops;
+bool supported;
+
+if (!key) {
+virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+   _("query-cpu-model-expansion reply data is missing a"
+ " property name"));
+return -1;
+}
+if (VIR_STRDUP(machine_model->props[n].name, key) < 0)
+return -1;
+
+if (virJSONValueGetBoolean(virJSONValueCopy(value), ) < 0) {
+virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+   _("query-cpu-model-expansion reply data is missing a"
+ " feature support value"));
+return -1;
+}
+machine_model->props[n].supported = suppo

[libvirt] [PATCH v2 05/11] qemu: command: Support new cpu feature argument syntax

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

Qemu has abandoned the +/-feature syntax in favor of key=value. Some
architectures (s390) do not support +/-feature. So we update libvirt to handle
both formats.

If we detect a sufficiently new Qemu (indicated by support for qmp
query-cpu-model-expansion) we use key=value else we fall back to +/-feature.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/qemu/qemu_command.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index f8e48d2..12e8aba 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -6672,12 +6672,18 @@ qemuBuildCpuModelArgStr(virQEMUDriverPtr driver,
 switch ((virCPUFeaturePolicy) cpu->features[i].policy) {
 case VIR_CPU_FEATURE_FORCE:
 case VIR_CPU_FEATURE_REQUIRE:
-virBufferAsprintf(buf, ",+%s", cpu->features[i].name);
+if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION))
+virBufferAsprintf(buf, ",%s=on", cpu->features[i].name);
+else
+virBufferAsprintf(buf, ",+%s", cpu->features[i].name);
 break;
 
 case VIR_CPU_FEATURE_DISABLE:
 case VIR_CPU_FEATURE_FORBID:
-virBufferAsprintf(buf, ",-%s", cpu->features[i].name);
+if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION))
+virBufferAsprintf(buf, ",%s=off", cpu->features[i].name);
+else
+virBufferAsprintf(buf, ",-%s", cpu->features[i].name);
 break;
 
 case VIR_CPU_FEATURE_OPTIONAL:
-- 
2.7.4

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

[libvirt] [PATCH v2 07/11] tests: qemuxml2argv s390x cpu model

[Jason J. Herne]

Test cases for qemu s390x cpu model argument generation.

Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 .../qemuxml2argv-cpu-s390-zEC12.args| 19 +++
 .../qemuxml2argv-cpu-s390-zEC12.xml | 21 +
 tests/qemuxml2argvtest.c| 12 
 3 files changed, 52 insertions(+)
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.xml

diff --git a/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.args 
b/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.args
new file mode 100644
index 000..4c95d6a
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.args
@@ -0,0 +1,19 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-kvm \
+-name guest1 \
+-S \
+-M s390-ccw-virtio \
+-cpu zEC12 \
+-m 214 \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
+-nographic \
+-nodefaults \
+-monitor unix:/tmp/lib/domain--1-guest1/monitor.sock,server,nowait \
+-no-acpi \
+-boot c
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.xml 
b/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.xml
new file mode 100644
index 000..de55f22
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.xml
@@ -0,0 +1,21 @@
+
+  guest1
+  c7a5fdbd-edaf-9455-926a-d65c16db1809
+  219100
+  219100
+  1
+  
+hvm
+  
+  
+  destroy
+  restart
+  destroy
+  
+zEC12
+  
+  
+  /usr/bin/qemu-kvm
+  
+  
+
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 81c62ac..bd2cdcb 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -300,6 +300,9 @@ testAddCPUModels(virQEMUCapsPtr caps, bool skipLegacy)
 const char *ppc64Models[] = {
 "POWER8", "POWER7",
 };
+const char *s390xModels[] = {
+"z990", "zEC12", "z13",
+};
 
 if (ARCH_IS_X86(arch)) {
 if (virQEMUCapsAddCPUDefinitions(caps, VIR_DOMAIN_VIRT_KVM, x86Models,
@@ -337,6 +340,11 @@ testAddCPUModels(virQEMUCapsPtr caps, bool skipLegacy)
  ARRAY_CARDINALITY(ppc64Models),
  VIR_DOMCAPS_CPU_USABLE_UNKNOWN) < 0)
 return -1;
+} else if (ARCH_IS_S390(arch)) {
+if (virQEMUCapsAddCPUDefinitions(caps, VIR_DOMAIN_VIRT_KVM, 
s390xModels,
+ ARRAY_CARDINALITY(s390xModels),
+ VIR_DOMCAPS_CPU_USABLE_UNKNOWN) < 0)
+return -1;
 }
 
 return 0;
@@ -1512,6 +1520,10 @@ mymain(void)
 DO_TEST_FAILURE("cpu-host-passthrough", NONE);
 DO_TEST_FAILURE("cpu-qemu-host-passthrough", QEMU_CAPS_KVM);
 
+qemuTestSetHostArch(driver.caps, VIR_ARCH_S390X);
+DO_TEST("cpu-s390-zEC12", QEMU_CAPS_KVM, QEMU_CAPS_VIRTIO_CCW, 
QEMU_CAPS_VIRTIO_S390);
+qemuTestSetHostArch(driver.caps, VIR_ARCH_NONE);
+
 qemuTestSetHostCPU(driver.caps, cpuHaswell);
 DO_TEST("cpu-Haswell", QEMU_CAPS_KVM);
 DO_TEST("cpu-Haswell2", QEMU_CAPS_KVM);
-- 
2.7.4

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

[libvirt] [PATCH v2 08/11] tests: qemuxml2argv cpu feature syntax

[Jason J. Herne]

Test that libvirt generates the correct cpu feature syntax when
query-cpu-model-expansion is supported and when it is not.

Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 .../qemuxml2argv-cpu-features-post-qcme.args   | 19 ++
 .../qemuxml2argv-cpu-features-post-qcme.xml| 23 ++
 .../qemuxml2argv-cpu-features-pre-qcme.args| 19 ++
 .../qemuxml2argv-cpu-features-pre-qcme.xml | 23 ++
 tests/qemuxml2argvtest.c   |  7 +++
 5 files changed, 91 insertions(+)
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-cpu-features-post-qcme.args
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-cpu-features-post-qcme.xml
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-cpu-features-pre-qcme.args
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-cpu-features-pre-qcme.xml

diff --git a/tests/qemuxml2argvdata/qemuxml2argv-cpu-features-post-qcme.args 
b/tests/qemuxml2argvdata/qemuxml2argv-cpu-features-post-qcme.args
new file mode 100644
index 000..07abc93
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-cpu-features-post-qcme.args
@@ -0,0 +1,19 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-kvm \
+-name guest1 \
+-S \
+-M s390-ccw-virtio \
+-cpu zEC12,dfppc=on,stckf=off \
+-m 214 \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
+-nographic \
+-nodefaults \
+-monitor unix:/tmp/lib/domain--1-guest1/monitor.sock,server,nowait \
+-no-acpi \
+-boot c
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-cpu-features-post-qcme.xml 
b/tests/qemuxml2argvdata/qemuxml2argv-cpu-features-post-qcme.xml
new file mode 100644
index 000..47279c4
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-cpu-features-post-qcme.xml
@@ -0,0 +1,23 @@
+
+  guest1
+  c7a5fdbd-edaf-9455-926a-d65c16db1809
+  219100
+  219100
+  1
+  
+hvm
+  
+  
+  destroy
+  restart
+  destroy
+  
+zEC12
+
+
+  
+  
+  /usr/bin/qemu-kvm
+  
+  
+
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-cpu-features-pre-qcme.args 
b/tests/qemuxml2argvdata/qemuxml2argv-cpu-features-pre-qcme.args
new file mode 100644
index 000..4622014
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-cpu-features-pre-qcme.args
@@ -0,0 +1,19 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-kvm \
+-name guest1 \
+-S \
+-M s390-ccw-virtio \
+-cpu zEC12,+dfppc,-stckf \
+-m 214 \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
+-nographic \
+-nodefaults \
+-monitor unix:/tmp/lib/domain--1-guest1/monitor.sock,server,nowait \
+-no-acpi \
+-boot c
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-cpu-features-pre-qcme.xml 
b/tests/qemuxml2argvdata/qemuxml2argv-cpu-features-pre-qcme.xml
new file mode 100644
index 000..47279c4
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-cpu-features-pre-qcme.xml
@@ -0,0 +1,23 @@
+
+  guest1
+  c7a5fdbd-edaf-9455-926a-d65c16db1809
+  219100
+  219100
+  1
+  
+hvm
+  
+  
+  destroy
+  restart
+  destroy
+  
+zEC12
+
+
+  
+  
+  /usr/bin/qemu-kvm
+  
+  
+
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index bd2cdcb..1478d17 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -1522,6 +1522,13 @@ mymain(void)
 
 qemuTestSetHostArch(driver.caps, VIR_ARCH_S390X);
 DO_TEST("cpu-s390-zEC12", QEMU_CAPS_KVM, QEMU_CAPS_VIRTIO_CCW, 
QEMU_CAPS_VIRTIO_S390);
+
+/* Cpu feature tests for both possible formats:
+ * Qemu < 2.8  : no query-cpu-model-expansion support : +/-feature format
+ * Qemu >= 2.8 : query-cpu-model-expansion support: feature=state 
format
+ */
+DO_TEST("cpu-features-post-qcme", QEMU_CAPS_KVM, 
QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION);
+DO_TEST("cpu-features-pre-qcme", QEMU_CAPS_KVM);
 qemuTestSetHostArch(driver.caps, VIR_ARCH_NONE);
 
 qemuTestSetHostCPU(driver.caps, cpuHaswell);
-- 
2.7.4

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

[libvirt] [PATCH v2 06/11] docs: document cpu host-passthrough migration issue

[Jason J. Herne]

Documents in formatdomain.html that when migrating a guest
defined with the host-passthrough CPU model from a machine that
is running on a newer CPU model than the destination machine's
CPU model, it is very likely that the guest will crash upon
arrival.

Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 docs/formatdomain.html.in | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 9218eec..b7c1e87 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1292,7 +1292,11 @@
   understand. Though the downside of this mode is that the guest
   environment cannot be reproduced on different hardware. Thus, if you
   hit any bugs, you are on your own. Further details of that CPU can
-  be changed using feature elements.
+  be changed using feature elements. Migration of a guest
+  using host-passthrough is dangerous if the source and destination
+  hosts are not identical in both hardware and configuration. If such
+  a migration is attempted then the guest will very likely hang or
+  crash upon resuming execution on the destination host.
 
 
 In both host-model and host-passthrough
-- 
2.7.4

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

[libvirt] [PATCH v2 00/11] Qemu: s390: Cpu Model Support

[Jason J. Herne]

This patch set enables cpu model support for s390. The user can now set exact
cpu models, query supported models via virsh domcapabilities, and use host-model
and host-passthrough modes. The end result is that migration is safer because
Qemu will perform runnability checking on the destination host and quit with an
error if the guest's cpu model is not supported.   

Note: Some test data has been separated from corresponding test case updates for
ease of review.

Changelog
-

[v2]
* Added s390x cpu and capabilities tests
* Added cpu feature syntax tests
* Dropped patch: Warn when migrating host-passthrough
* Added patch: Document migrating host-passthrough is dangerous

s390: Cpu driver support for update and compare
 - Compare: Added comment explaining why s390 bypasses the cpuCompare operation
 - Update: Added error message explaining minimum match mode is not supported
 - Update: Ensure user is not using unsupported optional feature policy
 - Update: Use virCPUDefUpdateFeature to update/create user requested features
 - Other minor fixes
 
s390-cpu: Remove nodeData and decode
 - Completely remove nodeData and decode functions

qemu: qmp query-cpu-model-expansion command
 - Cleaned up debug print
 - Restructured qemuMonitorJSONGetCPUModelExpansion
 - Added more JSON parsing error handling
 - CPU model features now parsed via an iterator
 - qemuMonitorJSONGetCPUModelExpansion: Fixed double free of model ptr
 - Restructure qemuMonitorCPUModelInfoFree
 - Other minor fixes

qemu-caps: Get host model directly from Qemu when available
 - virQEMUCapsProbeQMPHostCPU: indentation fix
 - Fixed rebase error involving a missing 'goto cleanup;'.
 - Fix indentation in virQEMUCapsProbeQMPHostCPU
 - virQEMUCapsInitHostCPUModel now routes to virQEMUCapsCopyModelFromQEMU or
   virQEMUCapsCopyModelFromHost, depending on architecture.
 - Restructure hostCpu data in qemu caps cache xml
 - Other minor fixes

Collin L. Walling (6):
  qemu: qmp query-cpu-model-expansion command
  qemu-caps: Get host model directly from Qemu when available
  qemu: command: Support new cpu feature argument syntax
  test-data: Qemu caps replies and xml for s390x qemu 2.7 and 2.8
  tests: qemu capabilites: qemu 2.7 and 2.8 on s390x
  tests: domain capabilities: qemu 2.8 on s390x

Jason J. Herne (5):
  s390: Cpu driver support for update and compare
  s390-cpu: Remove nodeData and decode
  docs: document cpu host-passthrough migration issue
  tests: qemuxml2argv s390x cpu model
  tests: qemuxml2argv cpu feature syntax

 docs/formatdomain.html.in  | 6 +-
 po/POTFILES.in | 1 +
 src/cpu/cpu_s390.c |   103 +-
 src/qemu/qemu_capabilities.c   |   180 +-
 src/qemu/qemu_capabilities.h   | 1 +
 src/qemu/qemu_command.c|10 +-
 src/qemu/qemu_monitor.c|62 +
 src/qemu/qemu_monitor.h|22 +
 src/qemu/qemu_monitor_json.c   |   121 +
 src/qemu/qemu_monitor_json.h   |12 +
 tests/domaincapsschemadata/qemu_2.8.0.s390x.xml|   159 +
 tests/domaincapstest.c |14 +
 .../qemucapabilitiesdata/caps_2.7.0.s390x.replies  | 11999 +
 tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml|   140 +
 .../qemucapabilitiesdata/caps_2.8.0.s390x.replies  | 13380 +++
 tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml|   286 +
 tests/qemucapabilitiestest.c   | 4 +
 .../qemuxml2argv-cpu-features-post-qcme.args   |19 +
 .../qemuxml2argv-cpu-features-post-qcme.xml|23 +
 .../qemuxml2argv-cpu-features-pre-qcme.args|19 +
 .../qemuxml2argv-cpu-features-pre-qcme.xml |23 +
 .../qemuxml2argv-cpu-s390-zEC12.args   |19 +
 .../qemuxml2argv-cpu-s390-zEC12.xml|21 +
 tests/qemuxml2argvtest.c   |19 +
 tests/testutilsqemu.c  |39 +-
 tests/testutilsqemu.h  | 1 +
 26 files changed, 26642 insertions(+), 41 deletions(-)
 create mode 100644 tests/domaincapsschemadata/qemu_2.8.0.s390x.xml
 create mode 100644 tests/qemucapabilitiesdata/caps_2.7.0.s390x.replies
 create mode 100644 tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml
 create mode 100644 tests/qemucapabilitiesdata/caps_2.8.0.s390x.replies
 create mode 100644 tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-cpu-features-post-qcme.args
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-cpu-features-post-qcme.xml
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-cpu-features-pre-qcme.args
 create mode 100644 
tests/qemuxml2argvdata/qemuxml2argv-cpu-features-pre-qcme.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.args

[libvirt] [PATCH v2 01/11] s390: Cpu driver support for update and compare

[Jason J. Herne]

Implement compare for s390. Required to test the guest against the host for
guest cpu model runnability checking. We always return IDENTICAL to bypass
Libvirt's checking. s390 will rely on Qemu to perform the runnability checking.

Implement update for s390. required to support use of cpu "host-model" mode.

Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 po/POTFILES.in |  1 +
 src/cpu/cpu_s390.c | 73 --
 2 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/po/POTFILES.in b/po/POTFILES.in
index b0a1ed4..570ebf1 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -46,6 +46,7 @@ src/cpu/cpu.c
 src/cpu/cpu_arm.c
 src/cpu/cpu_map.c
 src/cpu/cpu_ppc64.c
+src/cpu/cpu_s390.c
 src/cpu/cpu_x86.c
 src/datatypes.c
 src/driver.c
diff --git a/src/cpu/cpu_s390.c b/src/cpu/cpu_s390.c
index 04a6bea..3efc948 100644
--- a/src/cpu/cpu_s390.c
+++ b/src/cpu/cpu_s390.c
@@ -71,15 +71,84 @@ s390DataFree(virCPUDataPtr data)
 VIR_FREE(data);
 }
 
+static virCPUCompareResult
+virCPUs390Compare(virCPUDefPtr host ATTRIBUTE_UNUSED,
+  virCPUDefPtr cpu ATTRIBUTE_UNUSED,
+  bool failMessages ATTRIBUTE_UNUSED)
+{
+/* s390 relies on Qemu to perform all runability checking. Return
+ * VIR_CPU_COMPARE_IDENTICAL to bypass Libvirt checking.
+ */
+return VIR_CPU_COMPARE_IDENTICAL;
+}
+
+static int
+virCPUs390Update(virCPUDefPtr guest,
+ const virCPUDef *host)
+{
+ virCPUDefPtr updated = NULL;
+ int ret = -1;
+ size_t i;
+
+ if (guest->match == VIR_CPU_MATCH_MINIMUM) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+_("match mode %s not supported"),
+virCPUMatchTypeToString(guest->match));
+ goto cleanup;
+ }
+
+ if (guest->mode != VIR_CPU_MODE_HOST_MODEL) {
+ ret = 0;
+ goto cleanup;
+ }
+
+ if (!host) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+_("unknown host CPU model"));
+ goto cleanup;
+ }
+
+ if (!(updated = virCPUDefCopyWithoutModel(guest)))
+ goto cleanup;
+
+ updated->mode = VIR_CPU_MODE_CUSTOM;
+ if (virCPUDefCopyModel(updated, host, true) < 0)
+ goto cleanup;
+
+ for (i = 0; i < guest->nfeatures; i++) {
+ if (guest->features[i].policy == VIR_CPU_FEATURE_OPTIONAL) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("Only cpu feature policies 'require' and 'disable' are "
+ "supported for %s"),
+ guest->features[i].name);
+ goto cleanup;
+}
+
+if (virCPUDefUpdateFeature(updated,
+   guest->features[i].name,
+   guest->features[i].policy) < 0)
+goto cleanup;
+ }
+
+ virCPUDefStealModel(guest, updated, false);
+ guest->mode = VIR_CPU_MODE_CUSTOM;
+ guest->match = VIR_CPU_MATCH_EXACT;
+ ret = 0;
+
+ cleanup:
+ virCPUDefFree(updated);
+ return ret;
+}
+
 struct cpuArchDriver cpuDriverS390 = {
 .name = "s390",
 .arch = archs,
 .narch = ARRAY_CARDINALITY(archs),
-.compare= NULL,
+.compare= virCPUs390Compare,
 .decode = s390Decode,
 .encode = NULL,
 .free   = s390DataFree,
 .nodeData   = s390NodeData,
 .baseline   = NULL,
-.update = NULL,
+.update = virCPUs390Update,
 };
-- 
2.7.4

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

[libvirt] [PATCH v2 02/11] s390-cpu: Remove nodeData and decode

[Jason J. Herne]

On s390 , the host's features are heavily influenced by not only the host
hardware but also by hardware microcode level, host OS version, qemu
version and kvm version. In this environment it does not make sense to
attempt to report exact host details.

Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/cpu/cpu_s390.c | 36 ++--
 1 file changed, 2 insertions(+), 34 deletions(-)

diff --git a/src/cpu/cpu_s390.c b/src/cpu/cpu_s390.c
index 3efc948..68cd22f 100644
--- a/src/cpu/cpu_s390.c
+++ b/src/cpu/cpu_s390.c
@@ -33,38 +33,6 @@
 
 static const virArch archs[] = { VIR_ARCH_S390, VIR_ARCH_S390X };
 
-static virCPUDataPtr
-s390NodeData(virArch arch)
-{
-virCPUDataPtr data;
-
-if (VIR_ALLOC(data) < 0)
-return NULL;
-
-data->arch = arch;
-
-return data;
-}
-
-
-static int
-s390Decode(virCPUDefPtr cpu,
-   const virCPUData *data ATTRIBUTE_UNUSED,
-   const char **models ATTRIBUTE_UNUSED,
-   unsigned int nmodels ATTRIBUTE_UNUSED,
-   const char *preferred ATTRIBUTE_UNUSED,
-   unsigned int flags)
-{
-
-virCheckFlags(VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES, -1);
-
-if (cpu->model == NULL &&
-VIR_STRDUP(cpu->model, "host") < 0)
-return -1;
-
-return 0;
-}
-
 static void
 s390DataFree(virCPUDataPtr data)
 {
@@ -145,10 +113,10 @@ struct cpuArchDriver cpuDriverS390 = {
 .arch = archs,
 .narch = ARRAY_CARDINALITY(archs),
 .compare= virCPUs390Compare,
-.decode = s390Decode,
+.decode = NULL,
 .encode = NULL,
 .free   = s390DataFree,
-.nodeData   = s390NodeData,
+.nodeData   = NULL,
 .baseline   = NULL,
 .update = virCPUs390Update,
 };
-- 
2.7.4

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

Re: [libvirt] [PATCH 1/6] s390: Cpu driver support for update and compare

[Jason J. Herne]

On 11/28/2016 04:55 AM, Jiri Denemark wrote:
...

+static virCPUCompareResult
+virCPUs390Compare(virCPUDefPtr host ATTRIBUTE_UNUSED,
+ virCPUDefPtr cpu ATTRIBUTE_UNUSED,
+ bool failMessages ATTRIBUTE_UNUSED)


The indentation is a bit off here.


+{
+return VIR_CPU_COMPARE_IDENTICAL;
+}


I know there is no code to detect host CPU, but this essentially means
that any guest CPU configuration can be started on any s390 host (I'm
talking about KVM, of course). Is this correct or would it make sense to
somehow compare the guest CPU with the host model returned by QEMU?


We rely on Qemu to perform all runability checking. Not duplicating the
checks in Libvirt was a design choice. We are returning
VIR_CPU_COMPARE_IDENTICAL to essentially bypass Libvirt checking. perhaps
we should just comment that fact here?


Which reminds me I don't think I've ever seen any s390 CPU XML. Could
you just add some test cases focused on s390 CPUs to qemuxml2argvtest?


Sure :)


And since this series is largely about QEMU capabilities, it would be
nice if you could add a few .replies and corresponding .xml files to
tests/qemucapabilitiesdata and also use them in domaincapstest?


Yep.

...


Are you going to support additional features for host-model CPUs? In
other words, does the following XML make sense in s390?


  
  


If so, the code is insufficient. Otherwise, it's unnecessarily
complicated. There's no need to create "updated" CPU model when you
don't need to look at the features specified in the original guest CPU
definition.


Yes we are allowing policy='require' and policy='disable'. I don't 
understand

why the current code is insufficient. It seems like virCPUDefPtr
guest->features already has the guest's features with the correct policy
statements. Our call to virCPUDefStealModel will copy the features pointer
from guest to updated. What am I missing.

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

[libvirt] [PATCH 0/6] Qemu: s390: Cpu Model Support

[Jason J. Herne]

This patch set enables cpu model support for s390. The user can now set exact
cpu models, query supported models via virsh domcapabilities, and use host-model
and host-passthrough modes. The end result is that migration is safer because
Qemu will perform runnability checking on the destination host and quit with an
error if the guest's cpu model is not supported.   

Big Thanks for Jiri and Eduardo for being patient and answering our questions
while we figured out what we were doing!

Collin L. Walling (5):
  s390: Stop reporting "host" for host model
  qemu: qmp query-cpu-model-expansion command
  qemu-caps: Get host model directly from Qemu when available
  qemu: migration: warn if migrating with host-passthrough
  qemu: command: Support new cpu feature argument syntax

Jason J. Herne (1):
  s390: Cpu driver support for update and compare

 po/POTFILES.in   |   1 +
 src/cpu/cpu_s390.c   |  61 
 src/qemu/qemu_capabilities.c | 109 +--
 src/qemu/qemu_capabilities.h |   1 +
 src/qemu/qemu_command.c  |  10 +++-
 src/qemu/qemu_migration.c|   4 ++
 src/qemu/qemu_monitor.c  |  60 
 src/qemu/qemu_monitor.h  |  22 +
 src/qemu/qemu_monitor_json.c |  94 +
 src/qemu/qemu_monitor_json.h |   6 +++
 10 files changed, 353 insertions(+), 15 deletions(-)

-- 
1.9.1

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

[libvirt] [PATCH 6/6] qemu: command: Support new cpu feature argument syntax

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

Qemu has abandoned the +/-feature syntax in favor of key=value. Some
architectures (s390) do not support +/-feature. So we update libvirt to handle
both formats.

If we detect a sufficiently new Qemu (indicated by support for qmp
query-cpu-model-expansion) we use key=value else we fall back to +/-feature.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/qemu/qemu_command.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 4a5fce3..1f2da19 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -6580,12 +6580,18 @@ qemuBuildCpuModelArgStr(virQEMUDriverPtr driver,
 switch ((virCPUFeaturePolicy) cpu->features[i].policy) {
 case VIR_CPU_FEATURE_FORCE:
 case VIR_CPU_FEATURE_REQUIRE:
-virBufferAsprintf(buf, ",+%s", cpu->features[i].name);
+if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION))
+virBufferAsprintf(buf, ",%s=on", cpu->features[i].name);
+else
+virBufferAsprintf(buf, ",+%s", cpu->features[i].name);
 break;
 
 case VIR_CPU_FEATURE_DISABLE:
 case VIR_CPU_FEATURE_FORBID:
-virBufferAsprintf(buf, ",-%s", cpu->features[i].name);
+if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION))
+virBufferAsprintf(buf, ",%s=off", cpu->features[i].name);
+else
+virBufferAsprintf(buf, ",-%s", cpu->features[i].name);
 break;
 
 case VIR_CPU_FEATURE_OPTIONAL:
-- 
1.9.1

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

[libvirt] [PATCH 3/6] qemu: qmp query-cpu-model-expansion command

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

query-cpu-model-expansion is used to get a list of features for a given cpu
model name or to get the model and features of the host hardware/environment
as seen by Qemu/kvm.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/qemu/qemu_monitor.c  | 60 
 src/qemu/qemu_monitor.h  | 22 +++
 src/qemu/qemu_monitor_json.c | 94 
 src/qemu/qemu_monitor_json.h |  6 +++
 4 files changed, 182 insertions(+)

diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index 0bfc1a8..927ef39 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -3615,6 +3615,66 @@ qemuMonitorCPUDefInfoFree(qemuMonitorCPUDefInfoPtr cpu)
 
 
 int
+qemuMonitorGetCPUModelExpansion(qemuMonitorPtr mon,
+const char *type,
+const char *model_name,
+qemuMonitorCPUModelInfoPtr *model_info)
+{
+VIR_DEBUG("model_info=%p", model_info);
+
+QEMU_CHECK_MONITOR_JSON(mon);
+
+return qemuMonitorJSONGetCPUModelExpansion(mon, type, model_name, 
model_info);
+}
+
+
+void
+qemuMonitorCPUModelInfoFree(qemuMonitorCPUModelInfoPtr model_info)
+{
+size_t i;
+
+if (!model_info)
+return;
+VIR_FREE(model_info->name);
+for (i = 0; i < model_info->nprops; i++)
+VIR_FREE(model_info->props[i].name);
+VIR_FREE(model_info);
+}
+
+
+qemuMonitorCPUModelInfoPtr
+qemuMonitorCPUModelInfoCopy(const qemuMonitorCPUModelInfo *orig)
+{
+qemuMonitorCPUModelInfoPtr copy;
+size_t i;
+
+if (VIR_ALLOC(copy) < 0)
+goto cleanup;
+
+if (VIR_ALLOC_N(copy->props, orig->nprops) < 0)
+goto cleanup;
+
+if (VIR_STRDUP(copy->name, orig->name) < 0)
+goto cleanup;
+
+copy->nprops = orig->nprops;
+
+for (i = 0; i < orig->nprops; i++) {
+if (VIR_STRDUP(copy->props[i].name, orig->props[i].name) < 0)
+goto cleanup;
+
+copy->props[i].supported = orig->props[i].supported;
+}
+
+return copy;
+
+ cleanup:
+qemuMonitorCPUModelInfoFree(copy);
+return NULL;
+}
+
+
+int
 qemuMonitorGetCommands(qemuMonitorPtr mon,
char ***commands)
 {
diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h
index a0e5075..9b49d18 100644
--- a/src/qemu/qemu_monitor.h
+++ b/src/qemu/qemu_monitor.h
@@ -920,6 +920,28 @@ int qemuMonitorGetCPUDefinitions(qemuMonitorPtr mon,
  qemuMonitorCPUDefInfoPtr **cpus);
 void qemuMonitorCPUDefInfoFree(qemuMonitorCPUDefInfoPtr cpu);
 
+typedef struct _qemuMonitorCPUModelInfo qemuMonitorCPUModelInfo;
+typedef qemuMonitorCPUModelInfo *qemuMonitorCPUModelInfoPtr;
+
+struct _qemuMonitorCPUModelInfo {
+char *name;
+size_t nprops;
+struct {
+char *name;
+bool supported;
+} *props;
+};
+
+int qemuMonitorGetCPUModelExpansion(qemuMonitorPtr mon,
+const char *type,
+const char *model_name,
+qemuMonitorCPUModelInfoPtr *model_info);
+
+void qemuMonitorCPUModelInfoFree(qemuMonitorCPUModelInfoPtr model_info);
+
+qemuMonitorCPUModelInfoPtr
+qemuMonitorCPUModelInfoCopy(const qemuMonitorCPUModelInfo *orig);
+
 int qemuMonitorGetCommands(qemuMonitorPtr mon,
char ***commands);
 int qemuMonitorGetEvents(qemuMonitorPtr mon,
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index ef8672c..af50997 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -4930,6 +4930,100 @@ qemuMonitorJSONGetCPUDefinitions(qemuMonitorPtr mon,
 return ret;
 }
 
+int
+qemuMonitorJSONGetCPUModelExpansion(qemuMonitorPtr mon,
+const char *type,
+const char *model_name,
+qemuMonitorCPUModelInfoPtr *model_info)
+{
+int ret = -1;
+virJSONValuePtr model;
+virJSONValuePtr cmd = NULL;
+virJSONValuePtr reply = NULL;
+virJSONValuePtr data;
+virJSONValuePtr cpu_model;
+virJSONValuePtr cpu_props;
+qemuMonitorCPUModelInfoPtr newmodel = NULL;
+char const *cpu_name;
+int n;
+size_t i;
+
+*model_info = NULL;
+
+if (!(model = virJSONValueNewObject()))
+goto cleanup;
+
+if (virJSONValueObjectAppendString(model, "name", model_name) < 0)
+goto cleanup;
+
+if (!(cmd = qemuMonitorJSONMakeCommand("query-cpu-model-expansion",
+   "s:type", type,
+   "a:model", model,
+   NULL

[libvirt] [PATCH 5/6] qemu: migration: warn if migrating with host-passthrough

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

Warn the user when migrating a guest that is using the host-passthrough cpu
mode. host-passthrough is not migration safe because the host hypervisor is not
attempting to block features that may not exist on the destination host.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/qemu/qemu_migration.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index d4a55d8..f721de7 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -3151,6 +3151,10 @@ qemuMigrationBeginPhase(virQEMUDriverPtr driver,
 if (priv->job.asyncJob == QEMU_ASYNC_JOB_MIGRATION_OUT)
 qemuMigrationJobSetPhase(driver, vm, QEMU_MIGRATION_PHASE_BEGIN3);
 
+if (vm->def->cpu && vm->def->cpu->mode == VIR_CPU_MODE_HOST_PASSTHROUGH)
+VIR_WARN("cpu mode 'host-passthrough' may fail migration if 
destination"
+ " machine is running an older cpu model.");
+
 if (!qemuMigrationIsAllowed(driver, vm, true, flags))
 goto cleanup;
 
-- 
1.9.1

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

[libvirt] [PATCH 2/6] s390: Stop reporting "host" for host model

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

On s390 , the host's features are heavily influenced by not only the host
hardware but also by hardware microcode level, host OS version, qemu
version and kvm version. In this environment it does not make sense to
attempt to report exact host details.

Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
---
 src/cpu/cpu_s390.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/src/cpu/cpu_s390.c b/src/cpu/cpu_s390.c
index 0073565..2ecbd28 100644
--- a/src/cpu/cpu_s390.c
+++ b/src/cpu/cpu_s390.c
@@ -48,20 +48,15 @@ s390NodeData(virArch arch)
 
 
 static int
-s390Decode(virCPUDefPtr cpu,
+s390Decode(virCPUDefPtr cpu ATTRIBUTE_UNUSED,
const virCPUData *data ATTRIBUTE_UNUSED,
const char **models ATTRIBUTE_UNUSED,
unsigned int nmodels ATTRIBUTE_UNUSED,
const char *preferred ATTRIBUTE_UNUSED,
unsigned int flags)
 {
-
 virCheckFlags(VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES, -1);
 
-if (cpu->model == NULL &&
-VIR_STRDUP(cpu->model, "host") < 0)
-return -1;
-
 return 0;
 }
 
-- 
1.9.1

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

[libvirt] [PATCH 4/6] qemu-caps: Get host model directly from Qemu when available

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

When qmp query-cpu-model-expansion is available probe Qemu for its view of the
host model. In kvm environments this can provide a more complete view of the
host model because features supported by Qemu and Kvm can be considered.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/qemu/qemu_capabilities.c | 109 +--
 src/qemu/qemu_capabilities.h |   1 +
 2 files changed, 105 insertions(+), 5 deletions(-)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index cfd090c..b2c70cf 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -352,6 +352,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
   "ivshmem-doorbell", /* 240 */
   "query-qmp-schema",
   "gluster.debug_level",
+  "query-cpu-model-expansion",
 );
 
 
@@ -394,6 +395,8 @@ struct _virQEMUCaps {
 size_t ngicCapabilities;
 virGICCapability *gicCapabilities;
 
+qemuMonitorCPUModelInfoPtr hostCPUModelInfo;
+
 /* Anything below is not stored in the cache since the values are
  * re-computed from the other fields or external data sources every
  * time we probe QEMU or load the results from the cache.
@@ -1493,7 +1496,8 @@ struct virQEMUCapsStringFlags virQEMUCapsCommands[] = {
 { "rtc-reset-reinjection", QEMU_CAPS_RTC_RESET_REINJECTION },
 { "migrate-incoming", QEMU_CAPS_INCOMING_DEFER },
 { "query-hotpluggable-cpus", QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS },
-{ "query-qmp-schema", QEMU_CAPS_QUERY_QMP_SCHEMA }
+{ "query-qmp-schema", QEMU_CAPS_QUERY_QMP_SCHEMA },
+{ "query-cpu-model-expansion", QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION},
 };
 
 struct virQEMUCapsStringFlags virQEMUCapsMigration[] = {
@@ -2131,6 +2135,10 @@ virQEMUCapsPtr virQEMUCapsNewCopy(virQEMUCapsPtr 
qemuCaps)
 !(ret->hostCPUModel = virCPUDefCopy(qemuCaps->hostCPUModel)))
 goto error;
 
+if (qemuCaps->hostCPUModelInfo &&
+!(ret->hostCPUModelInfo = 
qemuMonitorCPUModelInfoCopy(qemuCaps->hostCPUModelInfo)))
+goto error;
+
 if (VIR_ALLOC_N(ret->machineTypes, qemuCaps->nmachineTypes) < 0)
 goto error;
 ret->nmachineTypes = qemuCaps->nmachineTypes;
@@ -2741,6 +2749,18 @@ virQEMUCapsProbeQMPCPUDefinitions(virQEMUCapsPtr 
qemuCaps,
 return ret;
 }
 
+static int
+virQEMUCapsProbeQMPHostCPU(virQEMUCapsPtr qemuCaps,
+qemuMonitorPtr mon)
+{
+if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION) ||
+!virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
+return 0;
+
+return qemuMonitorGetCPUModelExpansion(mon, "static", "host",
+   >hostCPUModelInfo);
+}
+
 struct tpmTypeToCaps {
 int type;
 virQEMUCapsFlags caps;
@@ -2966,6 +2986,29 @@ virQEMUCapsCPUFilterFeatures(const char *name,
 }
 
 
+static int
+virQEMUCapsCopyModelFromQEMU(virCPUDefPtr dst,
+ const qemuMonitorCPUModelInfo *modelInfo)
+{
+size_t i;
+
+if (VIR_STRDUP(dst->model, modelInfo->name) < 0 ||
+VIR_ALLOC_N(dst->features, modelInfo->nprops) < 0)
+return -1;
+dst->nfeatures_max = modelInfo->nprops;
+dst->nfeatures = 0;
+
+for (i = 0; i < modelInfo->nprops; i++) {
+if (VIR_STRDUP(dst->features[i].name, modelInfo->props[i].name) < 0)
+return -1;
+dst->features[i].policy = VIR_CPU_FEATURE_REQUIRE;
+dst->nfeatures++;
+}
+
+return 0;
+}
+
+
 void
 virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
 virCapsPtr caps)
@@ -2978,7 +3021,8 @@ virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
 if (!virQEMUCapsGuestIsNative(caps->host.arch, qemuCaps->arch))
 goto error;
 
-if (caps->host.cpu && caps->host.cpu->model) {
+if ((caps->host.cpu && caps->host.cpu->model)
+|| qemuCaps->hostCPUModelInfo) {
 if (VIR_ALLOC(cpu) < 0)
 goto error;
 
@@ -2987,9 +3031,14 @@ virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
 cpu->mode = VIR_CPU_MODE_CUSTOM;
 cpu->match = VIR_CPU_MATCH_EXACT;
 
-if (virCPUDefCopyModelFilter(cpu, caps->host.cpu, true,
- virQEMUCapsCPUFilterFeatures, NULL) < 0)
-goto error;
+if (qemuCaps->hostCPUModelInfo) {
+if (virQEMUCapsCopyModelFromQEMU(cpu, qemuCaps->hostCPUModelInfo) 
< 0)
+goto error;
+} else {
+if (virCPUDefCopyModelFilter(cpu, caps->host.cpu, 

[libvirt] [PATCH 1/6] s390: Cpu driver support for update and compare

[Jason J. Herne]

Implement compare for s390. Required to test the guest against the host for
guest cpu model runnability checking. We always return IDENTICAL to bypass
Libvirt's checking. s390 will rely on Qemu to perform the runnability checking.

Implement update for s390. required to support use of cpu "host-model" mode.

Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 po/POTFILES.in |  1 +
 src/cpu/cpu_s390.c | 54 --
 2 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/po/POTFILES.in b/po/POTFILES.in
index 25867ae..ea70e33 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -46,6 +46,7 @@ src/cpu/cpu.c
 src/cpu/cpu_arm.c
 src/cpu/cpu_map.c
 src/cpu/cpu_ppc64.c
+src/cpu/cpu_s390.c
 src/cpu/cpu_x86.c
 src/datatypes.c
 src/driver.c
diff --git a/src/cpu/cpu_s390.c b/src/cpu/cpu_s390.c
index 04a6bea..0073565 100644
--- a/src/cpu/cpu_s390.c
+++ b/src/cpu/cpu_s390.c
@@ -71,15 +71,65 @@ s390DataFree(virCPUDataPtr data)
 VIR_FREE(data);
 }
 
+static virCPUCompareResult
+virCPUs390Compare(virCPUDefPtr host ATTRIBUTE_UNUSED,
+ virCPUDefPtr cpu ATTRIBUTE_UNUSED,
+ bool failMessages ATTRIBUTE_UNUSED)
+{
+return VIR_CPU_COMPARE_IDENTICAL;
+}
+
+static int
+virCPUs390Update(virCPUDefPtr guest,
+ const virCPUDef *host)
+{
+ virCPUDefPtr updated = NULL;
+ int ret = -1;
+
+ if (guest->match == VIR_CPU_MATCH_MINIMUM) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+_("Match mode %s not supported"),
+virCPUMatchTypeToString(guest->match));
+ goto cleanup;
+ }
+
+ if (guest->mode != VIR_CPU_MODE_HOST_MODEL) {
+ ret = 0;
+ goto cleanup;
+ }
+
+ if (!host) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+_("unknown host CPU model"));
+ goto cleanup;
+ }
+
+ if (!(updated = virCPUDefCopyWithoutModel(guest)))
+ goto cleanup;
+
+ updated->mode = VIR_CPU_MODE_CUSTOM;
+ if (virCPUDefCopyModel(updated, host, true) < 0)
+ goto cleanup;
+
+ virCPUDefStealModel(guest, updated, false);
+ guest->mode = VIR_CPU_MODE_CUSTOM;
+ guest->match = VIR_CPU_MATCH_EXACT;
+ ret = 0;
+
+ cleanup:
+ virCPUDefFree(updated);
+ return ret;
+}
+
 struct cpuArchDriver cpuDriverS390 = {
 .name = "s390",
 .arch = archs,
 .narch = ARRAY_CARDINALITY(archs),
-.compare= NULL,
+.compare= virCPUs390Compare,
 .decode = s390Decode,
 .encode = NULL,
 .free   = s390DataFree,
 .nodeData   = s390NodeData,
 .baseline   = NULL,
-.update = NULL,
+.update = virCPUs390Update,
 };
-- 
1.9.1

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

Re: [libvirt] [PATCH 2/5] s390: Report blank host model instead of "host"

[Jason J. Herne]

On 11/03/2016 08:54 AM, Jiri Denemark wrote:

On Wed, Nov 02, 2016 at 16:34:32 -0400, Jason J. Herne wrote:

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

On s390 , the host's features are heavily influenced by not only the host
hardware but also by hardware microcode level, host OS version, qemu
version and kvm version. In this environment it does not make sense to
attempt to report exact host details. Rather than use the generic "host"
we leave this field blank.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/cpu/cpu_s390.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/cpu/cpu_s390.c b/src/cpu/cpu_s390.c
index 0f94084..c75eacb 100644
--- a/src/cpu/cpu_s390.c
+++ b/src/cpu/cpu_s390.c
@@ -59,7 +59,7 @@ s390Decode(virCPUDefPtr cpu,
 virCheckFlags(VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES, -1);

 if (cpu->model == NULL &&
-VIR_STRDUP(cpu->model, "host") < 0)
+VIR_STRDUP(cpu->model, "") < 0)
 return -1;

 return 0;


I think this function shouldn't do anything. Reporting "host" or even ""
as host CPU is pointless. If we cannot provide anything reasonable, we
should not report it at all.


I would agree. But virsh domcapabilities only indicates support for 
host-model

mode if we have something in cpu->hostModel.

virDomainCapsCPUFormat()
...
if (cpu->hostModel) {
virBufferAddLit(buf, "supported='yes'>\n");

It also causes the guest to fail when trying to use host-model mode
because virQEMUCapsInitHostCPUModel() skips setting qemuCaps->hostCPUModel
if caps->host.cpu->model does not exist.

Using an empty string here fixes both. Should I stick with it, or should we
fix the problems elsewhere?

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] [RFC 0/5] Qemu: s390: Cpu Model Support

[Jason J. Herne]

On 11/03/2016 09:37 AM, Jiri Denemark wrote:

On Wed, Nov 02, 2016 at 16:34:30 -0400, Jason J. Herne wrote:

...



2. virsh baseline and compare support.

Both of these commands, for s390 at least, will need to spin up a Qemu session
with monitor to compute the result. The only place I see this done today is
qemu_capabilities. Rather than blindly duplicate the code, I guess we should
carve out some type of api for spinning up a monitor backed Qemu instance, yes?

...


Yes, we will probably need to add new APIs which would accept more
parameters, but I'd keep it for later.


Thanks for looking this series over. We'll get to work on making the 
changes you

suggest. Just one thing here.

I'm not sure if you are saying to leave baseline/compare for later. Or 
do you
mean we should hold off on the api that can be used by any qemu code to 
spawn a

helper qemu process?

If we are implementing baseline and compare then we'll need some way to 
invoke Qemu.


--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

[libvirt] [PATCH 4/5] qemu-caps: Get host model directly from Qemu when available

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

When qmp query-cpu-model-expansion is available probe Qemu for its view of the
host model. In kvm environments this can provide a more complete view of the
host model because features supported by Qemu and Kvm can be considered.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/qemu/qemu_capabilities.c | 88 +++-
 1 file changed, 87 insertions(+), 1 deletion(-)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 7a8202a..4a6ae07 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -389,6 +389,8 @@ struct _virQEMUCaps {
 size_t ngicCapabilities;
 virGICCapability *gicCapabilities;
 
+virCPUDefPtr hostCPUModelFromQemu;
+
 /* Anything below is not stored in the cache since the values are
  * re-computed from the other fields or external data sources every
  * time we probe QEMU or load the results from the cache.
@@ -2118,6 +2120,10 @@ virQEMUCapsPtr virQEMUCapsNewCopy(virQEMUCapsPtr 
qemuCaps)
 !(ret->hostCPUModel = virCPUDefCopy(qemuCaps->hostCPUModel)))
 goto error;
 
+if (qemuCaps->hostCPUModelFromQemu &&
+!(ret->hostCPUModelFromQemu = 
virCPUDefCopy(qemuCaps->hostCPUModelFromQemu)))
+goto error;
+
 if (VIR_ALLOC_N(ret->machineTypes, qemuCaps->nmachineTypes) < 0)
 goto error;
 ret->nmachineTypes = qemuCaps->nmachineTypes;
@@ -2728,6 +2734,51 @@ virQEMUCapsProbeQMPCPUDefinitions(virQEMUCapsPtr 
qemuCaps,
 return ret;
 }
 
+static int
+virQEMUCapsProbeQMPCPUModelExpansion(virQEMUCapsPtr qemuCaps,
+qemuMonitorPtr mon)
+{
+qemuMonitorCPUModelInfoPtr model_info;
+virCPUDefPtr hostcpumodel;
+int nfeatures;
+int ret = -1;
+size_t i;
+
+if (qemuMonitorGetCPUModelExpansion(mon, "static", "host", _info) < 
0)
+goto cleanup;
+
+if (model_info == NULL) {
+ret = 0;
+goto cleanup;
+}
+
+if (VIR_ALLOC(hostcpumodel) < 0)
+goto cleanup;
+
+if (VIR_STRDUP(hostcpumodel->model, model_info->name) < 0)
+goto cleanup;
+
+nfeatures = hostcpumodel->nfeatures = model_info->nprops;
+
+if (VIR_ALLOC_N(hostcpumodel->features, nfeatures) < 0)
+goto cleanup;
+
+for (i = 0; i < nfeatures; i++) {
+if (VIR_STRDUP(hostcpumodel->features[i].name, 
model_info->props[i].name) < 0)
+goto cleanup;
+
+hostcpumodel->features[i].policy = -1;
+}
+
+hostcpumodel->arch = qemuCaps->arch;
+qemuCaps->hostCPUModelFromQemu = virCPUDefCopy(hostcpumodel);
+ret = 0;
+
+ cleanup:
+virCPUDefFree(hostcpumodel);
+return ret;
+}
+
 struct tpmTypeToCaps {
 int type;
 virQEMUCapsFlags caps;
@@ -2958,6 +3009,7 @@ virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
 virCapsPtr caps)
 {
 virCPUDefPtr cpu = NULL;
+virCPUDefPtr src = NULL;
 
 if (!caps)
 return;
@@ -2974,7 +3026,10 @@ virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
 cpu->mode = VIR_CPU_MODE_CUSTOM;
 cpu->match = VIR_CPU_MATCH_EXACT;
 
-if (virCPUDefCopyModelFilter(cpu, caps->host.cpu, true,
+if (!(src = qemuCaps->hostCPUModelFromQemu))
+src = caps->host.cpu;
+
+if (virCPUDefCopyModelFilter(cpu, src, true,
  virQEMUCapsCPUFilterFeatures, NULL) < 0)
 goto error;
 }
@@ -3118,6 +3173,21 @@ virQEMUCapsLoadCache(virCapsPtr caps,
 }
 VIR_FREE(str);
 
+xmlNodePtr node;
+if ((node = virXPathNode("./host/cpu[1]", ctxt))) {
+xmlNodePtr oldNode = ctxt->node;
+ctxt->node = node;
+if (!(qemuCaps->hostCPUModelFromQemu = virCPUDefParseXML(node,
+ ctxt,
+ VIR_CPU_TYPE_HOST))) {
+virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+   _("missing host cpu data in QEMU capabilities 
cache"));
+goto cleanup;
+}
+ctxt->node = oldNode;
+node = NULL;
+}
+
 if ((n = virXPathNodeSet("./cpu", ctxt, )) < 0) {
 virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("failed to parse qemu capabilities cpus"));
@@ -3298,6 +3368,20 @@ virQEMUCapsFormatCache(virQEMUCapsPtr qemuCaps,
 virBufferAsprintf(, "%s\n",
   virArchToString(qemuCaps->arch));
 
+if (qemuCaps->hostCPUModelFromQemu) {
+virBufferAddLit(, "\n");
+virBufferAdjustIndent(, 2);
+   

[libvirt] [PATCH 5/5] s390: qemu: Support cpu host-model mode

[Jason J. Herne]

Look up the host model stored in qemuCaps for generation of the
-cpu model portion of the Qemu command line.

Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/qemu/qemu_command.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index b68da3d..3b7095a 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -6537,6 +6537,9 @@ qemuBuildCpuModelArgStr(virQEMUDriverPtr driver,
 virBufferAddLit(buf, "host");
 if (cpu->model)
 virBufferAsprintf(buf, ",compat=%s", cpu->model);
+} else if (ARCH_IS_S390(def->os.arch)) {
+virCPUDefPtr guestCpu = virQEMUCapsGetHostModel(qemuCaps);
+virBufferAdd(buf, guestCpu->model, -1);
 } else {
 virReportError(VIR_ERR_INTERNAL_ERROR,
_("unexpected host-model CPU for %s architecture"),
-- 
1.9.1

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

[libvirt] [PATCH 2/5] s390: Report blank host model instead of "host"

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

On s390 , the host's features are heavily influenced by not only the host
hardware but also by hardware microcode level, host OS version, qemu
version and kvm version. In this environment it does not make sense to
attempt to report exact host details. Rather than use the generic "host"
we leave this field blank.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/cpu/cpu_s390.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/cpu/cpu_s390.c b/src/cpu/cpu_s390.c
index 0f94084..c75eacb 100644
--- a/src/cpu/cpu_s390.c
+++ b/src/cpu/cpu_s390.c
@@ -59,7 +59,7 @@ s390Decode(virCPUDefPtr cpu,
 virCheckFlags(VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES, -1);
 
 if (cpu->model == NULL &&
-VIR_STRDUP(cpu->model, "host") < 0)
+VIR_STRDUP(cpu->model, "") < 0)
 return -1;
 
 return 0;
-- 
1.9.1

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

[libvirt] [PATCH 3/5] qemu: qmp query-cpu-model-expansion command

[Jason J. Herne]

From: "Collin L. Walling" <wall...@linux.vnet.ibm.com>

query-cpu-model-expansion is used to get a list of features for a given cpu
model name or to get the model and features of the host hardware/environment
as seen by Qemu/kvm.

Signed-off-by: Collin L. Walling <wall...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/qemu/qemu_monitor.c  | 28 +
 src/qemu/qemu_monitor.h  | 19 +
 src/qemu/qemu_monitor_json.c | 98 
 src/qemu/qemu_monitor_json.h |  6 +++
 4 files changed, 151 insertions(+)

diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index a5e14b2..a7f056b 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -3615,6 +3615,34 @@ qemuMonitorCPUDefInfoFree(qemuMonitorCPUDefInfoPtr cpu)
 
 
 int
+qemuMonitorGetCPUModelExpansion(qemuMonitorPtr mon,
+const char *type,
+const char *model_name,
+qemuMonitorCPUModelInfoPtr *model_info)
+{
+VIR_DEBUG("model_info=%p", model_info);
+
+QEMU_CHECK_MONITOR_JSON(mon);
+
+return qemuMonitorJSONGetCPUModelExpansion(mon, type, model_name, 
model_info);
+}
+
+
+void
+qemuMonitorCPUModelInfoFree(qemuMonitorCPUModelInfoPtr model_info)
+{
+size_t i;
+
+if (!model_info)
+return;
+VIR_FREE(model_info->name);
+for (i = 0; i < model_info->nprops; i++)
+VIR_FREE(model_info->props[i].name);
+VIR_FREE(model_info);
+}
+
+
+int
 qemuMonitorGetCommands(qemuMonitorPtr mon,
char ***commands)
 {
diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h
index c3133c4..60e72df 100644
--- a/src/qemu/qemu_monitor.h
+++ b/src/qemu/qemu_monitor.h
@@ -920,6 +920,25 @@ int qemuMonitorGetCPUDefinitions(qemuMonitorPtr mon,
  qemuMonitorCPUDefInfoPtr **cpus);
 void qemuMonitorCPUDefInfoFree(qemuMonitorCPUDefInfoPtr cpu);
 
+typedef struct _qemuMonitorCPUModelInfo qemuMonitorCPUModelInfo;
+typedef qemuMonitorCPUModelInfo *qemuMonitorCPUModelInfoPtr;
+
+struct _qemuMonitorCPUModelInfo {
+char *name;
+size_t nprops;
+struct {
+char *name;
+bool supported;
+} *props;
+};
+
+int qemuMonitorGetCPUModelExpansion(qemuMonitorPtr mon,
+const char *type,
+const char *model_name,
+qemuMonitorCPUModelInfoPtr *model_info);
+
+void qemuMonitorCPUModelInfoFree(qemuMonitorCPUModelInfoPtr model_info);
+
 int qemuMonitorGetCommands(qemuMonitorPtr mon,
char ***commands);
 int qemuMonitorGetEvents(qemuMonitorPtr mon,
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index 6c13832..dbb92e1 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -4975,6 +4975,104 @@ qemuMonitorJSONGetCPUDefinitions(qemuMonitorPtr mon,
 return ret;
 }
 
+int
+qemuMonitorJSONGetCPUModelExpansion(qemuMonitorPtr mon,
+const char *type,
+const char *model_name,
+qemuMonitorCPUModelInfoPtr *model_info)
+{
+int ret = -1;
+virJSONValuePtr model;
+virJSONValuePtr cmd = NULL;
+virJSONValuePtr reply = NULL;
+virJSONValuePtr data;
+virJSONValuePtr cpu_model;
+virJSONValuePtr cpu_props;
+qemuMonitorCPUModelInfoPtr newmodel = NULL;
+char const *cpu_name;
+int n;
+size_t i;
+
+*model_info = NULL;
+
+if (!(model = virJSONValueNewObject()))
+goto cleanup;
+
+if (virJSONValueObjectAppendString(model, "name", model_name) < 0)
+goto cleanup;
+
+if (!(cmd = qemuMonitorJSONMakeCommand("query-cpu-model-expansion",
+   "s:type", type,
+   "a:model", model,
+   NULL)))
+goto cleanup;
+
+if (qemuMonitorJSONCommand(mon, cmd, ) < 0)
+goto cleanup;
+
+if (qemuMonitorJSONHasError(reply, "GenericError")) {
+ret = 0;
+goto cleanup;
+}
+
+if (qemuMonitorJSONCheckError(cmd, reply) < 0)
+goto cleanup;
+
+if (!(data = virJSONValueObjectGetObject(reply, "return"))) {
+virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+   _("query-cpu-model-expansion reply was missing return 
data"));
+goto cleanup;
+}
+
+if (!(cpu_model = virJSONValueObjectGetObject(data, "model")))
+goto cleanup;
+
+if (!(cpu_name = virJSONValueObjectGetString(cpu_model, "name")))
+goto cleanup;
+
+if (!(cpu_props = virJSONValueObjectGetObject(cpu_model, "props")

[libvirt] [PATCH 1/5] s390: Cpu driver support for getModels, update and compare

[Jason J. Herne]

Implement getModels for s390. It returns an empty list. This means libvirt
supports all models Qemu knows about.

Implement compare for s390. Required to test the guest against the host for
guest cpu model runnability checking. We always return IDENTICAL to bypass
Libvirt's checking. s390 will rely on Qemu to perform the runnability checking.

Implement update for s390. required to support use of cpu "host-model" mode.

Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/cpu/cpu_s390.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/src/cpu/cpu_s390.c b/src/cpu/cpu_s390.c
index fb352a0..0f94084 100644
--- a/src/cpu/cpu_s390.c
+++ b/src/cpu/cpu_s390.c
@@ -71,16 +71,43 @@ s390DataFree(virCPUDataPtr data)
 VIR_FREE(data);
 }
 
+static int
+s390GetModels(char ***models ATTRIBUTE_UNUSED)
+{
+return 0;
+}
+
+static virCPUCompareResult
+virCPUs390Compare(virCPUDefPtr host ATTRIBUTE_UNUSED,
+ virCPUDefPtr cpu ATTRIBUTE_UNUSED,
+ bool failMessages ATTRIBUTE_UNUSED)
+{
+return VIR_CPU_COMPARE_IDENTICAL;
+}
+
+static int
+virCPUs390Update(virCPUDefPtr guest ATTRIBUTE_UNUSED,
+ const virCPUDef *host ATTRIBUTE_UNUSED)
+{
+/*
+ * - host-passthrough not yet supported
+ * - host-model needs no changes
+ * - custom mode ... ???
+ */
+return 0;
+}
+
 struct cpuArchDriver cpuDriverS390 = {
 .name = "s390",
 .arch = archs,
 .narch = ARRAY_CARDINALITY(archs),
-.compare= NULL,
+.compare= virCPUs390Compare,
 .decode = s390Decode,
 .encode = NULL,
 .free   = s390DataFree,
 .nodeData   = s390NodeData,
 .guestData  = NULL,
 .baseline   = NULL,
-.update = NULL,
+.update = virCPUs390Update,
+.getModels  = s390GetModels,
 };
-- 
1.9.1

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

[libvirt] [RFC 0/5] Qemu: s390: Cpu Model Support

[Jason J. Herne]

Thanks for all your feedback up to this point. We've made some progress on this
and we also have a few questions. Please let us know if we're on the right track
or if we're off in the weeds on this.

Here is what we have so far.

Patch #1 updates s390's cpu driver to support some operations needed for cpu
model support within Libvirt's existing infrastructure.

Patch #2 removes s390's hard coded "host" model string. Jiri thought it made
more sense to simply leave this blank.

Path #3 adds qmp query-cpu-model-expansion command.

Patch #4 probes Qemu's view of the host model (query-cpu-model-expansion),
caches the response and uses it to fill in qemuCaps->hostCpuModel. Archs that
do not implement query-cpu-model-expansion will continue to fill in
qemuCaps->hostCpuModel from caps->host.cpu.

Patch #5 updates qemuBuildCpuModelArgStr's VIR_CPU_MODE_HOST_MODEL case. It
seems like all archs except PPC64 do not support host model mode. We add an s390
path here and get the guest cpu model from virQEMUCapsGetHostModel() which will
get the model name from qemuCaps->hostCpuModel.
NOTE: I just realized we'll need need to handle the case where
virQEMUCapsGetHostModel returns NULL or the model is NULL or "". We probably
should just throw an error and give up in that case.

Here is a list of outstanding things to do and some questions.

1. virsh domcapabilities --emulatorbin flag

This works today if the command is passed --emulatorbin /usr/bin/qemu-kvm.
If no emulatorbin is given then Libvirt seems to choose
/usr/bin/qemu-system-s390x my system which does not have kvm enabled.

A kvm session is needed for s390 to properly compute the host model. A kvm
session is only available for the qemu-kvm binary. 

Is the answer to tell our users to always supply --emulatorbin with
/usr/bin/qemu-kvm argument? Or is there a more user friendly solution to this?

2. virsh baseline and compare support.

Both of these commands, for s390 at least, will need to spin up a Qemu session
with monitor to compute the result. The only place I see this done today is
qemu_capabilities. Rather than blindly duplicate the code, I guess we should
carve out some type of api for spinning up a monitor backed Qemu instance, yes?

Also, neither compare nor baseline have the --emulatorbin flag. So we'll either
need to add them or find an alternate solution. Any thoughts on this?

3.Support host passthrough mode.

This essentially just means passing -cpu host to qemu. We know Qemu supports
this for s390 today. But Libvirt claims it is not supported due to the
following:

  In virQEMUCapsIsCPUModeSupported, our virt "type" is VIR_DOMAIN_VIRT_QEMU, and
  not VIR_DOMAIN_VIRT_KVM.
  
  virttype comes from domCaps and is set here: 
qemuConnectGetDomainCapabilities()
  The relevant code is:
  
  if (qemuHostdevHostSupportsPassthroughLegacy() ||
  qemuHostdevHostSupportsPassthroughVFIO())
  virttype = VIR_DOMAIN_VIRT_KVM;
  else
  virttype = VIR_DOMAIN_VIRT_QEMU;

I'll admit, I have not been able to figure out why these checks are failing in
my test environment, when I suspect they should be passing. But in my case it
seems as though these relate to host device passthrough. How do they apply to
cpu model passthrough. What am I missing?

Thanks for your time.

Collin L. Walling (3):
  s390: Report blank host model instead of "host"
  qemu: qmp query-cpu-model-expansion command
  qemu-caps: Get host model directly from Qemu when available

Jason J. Herne (2):
  s390: Cpu driver support for getModels, update and compare
  s390: qemu: Support cpu host-model mode

 src/cpu/cpu_s390.c   | 33 +--
 src/qemu/qemu_capabilities.c | 88 ++-
 src/qemu/qemu_command.c  |  3 ++
 src/qemu/qemu_monitor.c  | 28 +
 src/qemu/qemu_monitor.h  | 19 +
 src/qemu/qemu_monitor_json.c | 98 
 src/qemu/qemu_monitor_json.h |  6 +++
 7 files changed, 271 insertions(+), 4 deletions(-)

-- 
1.9.1

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

Re: [libvirt] Cpu Modeling

[Jason J. Herne]

On 09/29/2016 11:15 AM, Jiri Denemark wrote:

On Fri, Sep 23, 2016 at 15:51:12 -0400, Jason J. Herne wrote:

On 09/23/2016 08:05 AM, Jiri Denemark wrote:

The host-model part of the XML will show the result of
query-cpu-model-expansion on "host" model, or the result of querying the
hardware directly if we can't ask QEMU for that (which is the current
state).


So the expectation here is that virsh capabilities" reports actual host
cpu data. So for S390, we can leave our implementation of this "as-is"
and not report any features here, I'm guessing.


Yes.


And the  section from virsh domcapabilities will contain the Qemu
specific supported cpu modeling info. As you stated  will contain the name (and possibly feature
details?) of the model returned by qmp query-model-expansion on
'host'.


Right, the host-model part should basically contain the CPU
configuration which libvirt will use if a user asks for host-model. For
example (on x86_64, since I have no experience with s390), the following
XML

 
   Skylake-Client
   Intel
   
   
 

would result in "-cpu Skylake-Client,+vmx,+tsc_adjust" QEMU command line.



Jiri,

In order to properly obtain the host cpu model data for virsh 
capabilities on
s390 we will need to run a Qemu process. There is no precedent for doing 
this

in a cpu connection driver today. I can imagine two ways to do this:

1. The s390 cpu connection driver (src/cpu/cpu_s390.c) can just 
privately make

use of the default Qemu binary and the appropriate qmp calls can be made to
get the model name and possibly features.

2. We can extend the existing interface somehow so all archs could make 
use of
a hypervisor instance for nodeData() and decode() operations. Perhaps a 
new set
of callbacks? nodeDataWithHypervisor(), decodeWithHypervisor() ? We'd 
have to

modify the generic versions of these functions to try one set of interfaces,
then the other in case the first set is not supported for a given arch.

Do either of these sound sane to you, or am I way off on this?

I'm trying to get the host cpu model for virCapsPtr caps, as it is filled in
via virQEMUCapsInit --> virQEMUCapsInitCPU. And subsequently referenced for
the output of virsh capabilities and copied into qemuCaps for reference by
virsh domcapabilities.

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] [PATCH v3] qemu-migration: Disallow migration of read only disk

[Jason J. Herne]

Polite ping? :)

On 09/26/2016 01:16 PM, Corey S. McQuay wrote:

Currently Libvirt allows attempts to migrate read only disks. Qemu cannot 
handle this as read only
disks cannot be written to on the destination system. The end result is a 
cryptic error message
and a failed migration.

This patch causes migration to fail earlier and provides a meaningful error 
message stating that
migrating read only disks is not supported.

Signed-off-by: Corey S. McQuay <csmcq...@linux.vnet.ibm.com>
Reviewed-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiu...@linux.vnet.ibm.com>
---
  src/qemu/qemu_migration.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index e451ef6..c8fb7ec 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -1764,6 +1764,12 @@ qemuMigrationStartNBDServer(virQEMUDriverPtr driver,
  /* check whether disk should be migrated */
  if (!qemuMigrateDisk(disk, nmigrate_disks, migrate_disks))
  continue;
+
+if (disk->src->readonly) {
+virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
+_("Cannot migrate read-only disk %s"), disk->dst);
+goto cleanup;
+}

  VIR_FREE(diskAlias);
  if (!(diskAlias = qemuAliasFromDisk(disk)))



--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] Cpu Modeling

[Jason J. Herne]

Polite Ping? :)

On 09/23/2016 03:51 PM, Jason J. Herne wrote:

On 09/23/2016 08:05 AM, Jiri Denemark wrote:

On Thu, Sep 22, 2016 at 14:47:36 -0400, Jason J. Herne wrote:

...

1. We will invoke qemu to gather the host cpu data used for virsh
capabilities. Today this data seems to be collected directly from the
host hardware for most (all?) architectures.


Not really, virsh capabilities will still contain data gathered directly
from the host hardware. But, we have virsh domcapabilities for
displaying data tight to a specific QEMU binary. Since yesterday
afternoon we have support for displaying CPU related data in the domain
capabilities XML; see
http://libvirt.org/formatdomaincaps.html#elementsCPU



The host-model part of the XML will show the result of
query-cpu-model-expansion on "host" model, or the result of querying the
hardware directly if we can't ask QEMU for that (which is the current
state).


So the expectation here is that virsh capabilities" reports actual host
cpu data. So for S390, we can leave our implementation of this "as-is"
and not report any features here, I'm guessing. And the 
section from virsh domcapabilities will contain the Qemu specific
supported cpu modeling info. As you stated 
will contain the name (and possibly feature details?) of the model
returned by qmp query-model-expansion on 'host'. Furthermore, the
 section will list all supported model names, as
indicated by qmp query-cpu-definitions. Do I have it right?


2. virsh cpu-models {arch} will also use a Qemu invocation to gather
cpu model data.


No, virsh cpu-models will just list CPU models supported by libvirt


So, in other words we just spit out whatever models Libvirt managed to
grab, and cache, from a call to qmp query-cpu-definitions? Or am I
missing something?


(or an empty list if libvirt supports all models supported by QEMU).


Can you clarify? It seems odd that an empty list would be returned here.
I thought the point was to list all supported cpu models. For x86 today
I imagine it is the list found in cpu_map.xml. For s390, this will be
the list we get back from qmp query-cpu-definitions, which as you mention
below, is found in the domain capabilities XML.


The CPU model data from QEMU can be found in domain capabilities XML.


3. Most architectures seem to use a "map" (xml file containing cpu
model data that ships with Libvirt) to satisfy #1 and #2 above. Our
new method does not use this map as it gets all of the data directly
from Qemu.


Even if we switch some CPU operations to work through QEMU, we may still
need to use the cpu_map.xml file for some other operations, or other
hypervisor driver. It all depends on what we need to do for a given
architecture. For example, ARM does not use cpu_map.xml at all even now.

Slightly related, I don't think we have a way to list CPU features
supported by QEMU over QMP, do we? "-cpu ?" will show them all, but I
couldn't find a QMP command that would give me the same list.



query-model-expansion will return all features of a given model name. Model
names can be enumerated via query-cpu-definitions.


4. virsh cpu-baseline and cpu-compare will now invoke qemu directly as
well.


Perhaps, but before we can do that, we'll probably need to come up with
new APIs. It don't think it's critical, though.


Do you mind elaborating on this a bit? Which APIs do we want to look at
here? Are you talking about new commands/calls to replace cpu-baseline
and cpu-compare?

Thanks again for your time.



--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] Cpu Modeling

[Jason J. Herne]

On 09/23/2016 08:05 AM, Jiri Denemark wrote:

On Thu, Sep 22, 2016 at 14:47:36 -0400, Jason J. Herne wrote:

...

1. We will invoke qemu to gather the host cpu data used for virsh
capabilities. Today this data seems to be collected directly from the
host hardware for most (all?) architectures.


Not really, virsh capabilities will still contain data gathered directly
from the host hardware. But, we have virsh domcapabilities for
displaying data tight to a specific QEMU binary. Since yesterday
afternoon we have support for displaying CPU related data in the domain
capabilities XML; see
http://libvirt.org/formatdomaincaps.html#elementsCPU



The host-model part of the XML will show the result of
query-cpu-model-expansion on "host" model, or the result of querying the
hardware directly if we can't ask QEMU for that (which is the current
state).


So the expectation here is that virsh capabilities" reports actual host
cpu data. So for S390, we can leave our implementation of this "as-is"
and not report any features here, I'm guessing. And the 
section from virsh domcapabilities will contain the Qemu specific
supported cpu modeling info. As you stated 
will contain the name (and possibly feature details?) of the model
returned by qmp query-model-expansion on 'host'. Furthermore, the
 section will list all supported model names, as
indicated by qmp query-cpu-definitions. Do I have it right?


2. virsh cpu-models {arch} will also use a Qemu invocation to gather
cpu model data.


No, virsh cpu-models will just list CPU models supported by libvirt


So, in other words we just spit out whatever models Libvirt managed to
grab, and cache, from a call to qmp query-cpu-definitions? Or am I
missing something?


(or an empty list if libvirt supports all models supported by QEMU).


Can you clarify? It seems odd that an empty list would be returned here.
I thought the point was to list all supported cpu models. For x86 today
I imagine it is the list found in cpu_map.xml. For s390, this will be
the list we get back from qmp query-cpu-definitions, which as you mention
below, is found in the domain capabilities XML.


The CPU model data from QEMU can be found in domain capabilities XML.


3. Most architectures seem to use a "map" (xml file containing cpu
model data that ships with Libvirt) to satisfy #1 and #2 above. Our
new method does not use this map as it gets all of the data directly
from Qemu.


Even if we switch some CPU operations to work through QEMU, we may still
need to use the cpu_map.xml file for some other operations, or other
hypervisor driver. It all depends on what we need to do for a given
architecture. For example, ARM does not use cpu_map.xml at all even now.

Slightly related, I don't think we have a way to list CPU features
supported by QEMU over QMP, do we? "-cpu ?" will show them all, but I
couldn't find a QMP command that would give me the same list.



query-model-expansion will return all features of a given model name. Model
names can be enumerated via query-cpu-definitions.


4. virsh cpu-baseline and cpu-compare will now invoke qemu directly as
well.


Perhaps, but before we can do that, we'll probably need to come up with
new APIs. It don't think it's critical, though.


Do you mind elaborating on this a bit? Which APIs do we want to look at
here? Are you talking about new commands/calls to replace cpu-baseline
and cpu-compare?

Thanks again for your time.

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

[libvirt] Cpu Modeling

[Jason J. Herne]

Hi Jiri & Eduardo,

You might remember a discussion with David Hildenbrand of IBM on the Qemu
mailing list regarding a new Qemu<->Libvirt interface for cpu modeling. I am
picking up this work from David and I wanted to confirm that we are 
still on the

same page as to the direction of that interface.

For your reference:
https://www.redhat.com/archives/libvir-list/2016-June/thread.html#01413
https://lists.gnu.org/archive/html/qemu-devel/2016-09/threads.html#00489

The first link is to the discussion you were directly involved in. The 
second
link is to the final patch set posted to qemu-devel. The cover letter 
gives a

good overview of the interface added to Qemu and the proposed use-case for
Libvirt to use this new cpu modeling support. I'll paste in the most 
relevant

section for your convenience:

Libvirt usecase
Testing for runability:
- Simply try to start QEMU with KVM, compat machine, CPU model
- Could be done using query-cpu-model-comparison in the future.

Identifying host model, e.g. "virsh capabilities"
- query-cpu-model-expansion on "host" with "-M none --enable-kvm"

:
- simply copy the identified host model

:
- "-cpu host"

"virsh cpu-baseline":
- query-cpu-model-baseline on two models with "-M none"

"virsh cpu-compare":
- query-cpu-model-comparison on two models with "-M none"

There might be some cenarios where libvirt wants to convert another CPU
model to a static variant, this can be done using query-cpu-model-expansion
---

Now that I've hopefully refreshed your memory :) I just want to make 
sure that

you are still on-board with this plan. I realize that this new approach does
things differently than Libvirt does today for other platforms. Especially
x86_64. The big differences are as follows:

1. We will invoke qemu to gather the host cpu data used for virsh 
capabilities.
Today this data seems to be collected directly from the host hardware 
for most

(all?) architectures.

2. virsh cpu-models {arch} will also use a Qemu invocation to gather cpu 
model

data.

3. Most architectures seem to use a "map" (xml file containing cpu model 
data
that ships with Libvirt) to satisfy #1 and #2 above. Our new method does 
not use

this map as it gets all of the data directly from Qemu.

4. virsh cpu-baseline and cpu-compare will now invoke qemu directly as well.

Note: I'm not sure exactly how much all of this will apply just to s390 with
other architectures moving over to the new interface if/when they want 
to. Or if
we will want to change all architectures to this new interface at the 
same time.

Any guidance?

Thanks for your time and consideration.

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] [PATCH] qemu-migration: Disallow migration of read only disk

[Jason J. Herne]

On 09/14/2016 10:40 AM, Daniel P. Berrange wrote:

On Wed, Sep 14, 2016 at 10:37:07AM -0400, Corey S. McQuay wrote:

Currently Libvirt allows attempts to migrate read only disks. Qemu cannot 
handle this as read only
disks cannot be written to on the destination system. The end result is a 
cryptic error message
and a failed migration.

This patch causes migration to fail earlier and provides a meaningful error 
message stating that
migrating read only disks is not supported.

Signed-off-by: Corey S. McQuay <csmcq...@linux.vnet.ibm.com>
Reviewed-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiu...@linux.vnet.ibm.com>
---
  src/qemu/qemu_migration.c | 25 +
  1 file changed, 25 insertions(+)

diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index e451ef6..3311711 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -2392,6 +2392,28 @@ qemuMigrationIsSafe(virDomainDefPtr def,
  return true;
  }

+static bool
+qemuMigrationAreAllDisksRW(virDomainDefPtr def,
+size_t nmigrate_disks,
+const char **migrate_disks)
+{
+size_t i;
+
+for (i = 0; i < def->ndisks; i++) {
+virDomainDiskDefPtr disk = def->disks[i];
+
+if (qemuMigrateDisk(disk, nmigrate_disks, migrate_disks) &&
+disk->src->readonly) {
+virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
+   _("Cannot migrate read-only disk %s"),
+   disk->dst);
+return false;
+}
+}
+
+return true;
+}


We already have multiple places in the migration code which iterate
over all disks, determining which are migratable. IMHO we should
just add an readonly check in one of those, rather than adding yet
another iteration.



Hi Daniel,

I'm not seeing a suitable existing location for this new check to live.
The only place I see migration code loop over the disks for error checking
is in qemuMigrationBeginPhase.

for (i = 0; i < nmigrate_disks; i++) {
for (j = 0; j < vm->def->ndisks; j++) {
if (STREQ(vm->def->disks[j]->dst, migrate_disks[i]))
break;
}

if (j == vm->def->ndisks) {
virReportError(VIR_ERR_INVALID_ARG,
   _("disk target %s not found"),
   migrate_disks[i]);
goto cleanup;
}
}

And putting inside a nested loop would be kind of silly :)
It seems to be that all other disk loops are in locations
that do not run before migration begins, or their purpose
is not for error checking.

It may make sense to add the check to either of the following:
qemuMigrationDriveMirror
qemuMigrationStartNBDServer

But I have not researched those enough yet to know for sure.
I'll look into these on Monday, unless someone can tell me in
the meantime if this makes sense or not?


--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] [PATCH v1] qemu-migration: Disallow migration of read only disk

[Jason J. Herne]

On 08/17/2016 05:10 PM, Jason J. Herne wrote:

On 08/11/2016 08:57 AM, Corey S McQuay wrote:

On 08/10/2016 09:16 AM, Koniszewski, Pawel wrote:


-Original Message-
From: libvir-list-boun...@redhat.com [mailto:libvir-list-
boun...@redhat.com] On Behalf Of Corey S. McQuay
Sent: Friday, August 5, 2016 8:34 PM
To: jjhe...@linux.vnet.ibm.com; libvir-list@redhat.com
Cc: Corey S. McQuay <csmcq...@linux.vnet.ibm.com>
Subject: [libvirt] [PATCH v1] qemu-migration: Disallow migration of
read only
disk

From: "Corey S. McQuay" <csmcq...@linux.vnet.ibm.com>

Currently Libvirt allows attempts to migrate read only disks. Qemu
cannot
handle this as read only disks cannot be written to on the
destination system.
The end result is a cryptic error message and a failed migration.

This patch causes migration to fail earlier and provides a meaningful
error
message stating that migrating read only disks is not supported.

What will happen if read-only disk is copied to destination prior to
migration start? Currently such scenario works, will it still work
with this code?

Based on our testing, pre-copying a read only disk image to the
destination system has no effect on the outcome of attempting to migrate
a non-shared read only disk. I'm not sure what scenario you are
referring to but here is what we tried:

Relevant guest xml:
 
   
   
   
   
   
   
   
 

The disk image exists at /disk-images/guest.iso on the source. Before
migration we copied the image to the same path on the destination
system. Then we attempted migration:

 virsh migrate --live --copy-storage-all --migrate-disks sdz
--verbose kvm1 qemu+ssh://dstHost/system tcp://dstHost

The error message we get is:

error: internal error: info migration reply was missing return status

Running journalctl shows additional information:

Aug 10 16:02:16 collin-kvm libvirtd[41616]: operation failed: migration
of disk sdz failed.

I'm pretty sure this patch does not stop the user from doing anything
that works today. But if your scenario is different from ours in some
way please let us know and we'll do some more testing.


Pawel,

Thanks for taking a look. Does Corey's reply address your concerns?



Polite ping for Pawel, and anyone else who wants to review. Thanks :)

Original patch here:
https://www.redhat.com/archives/libvir-list/2016-August/msg00378.html

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] [PATCH v1] qemu-migration: Disallow migration of read only disk

[Jason J. Herne]

On 08/11/2016 08:57 AM, Corey S McQuay wrote:

On 08/10/2016 09:16 AM, Koniszewski, Pawel wrote:


-Original Message-
From: libvir-list-boun...@redhat.com [mailto:libvir-list-
boun...@redhat.com] On Behalf Of Corey S. McQuay
Sent: Friday, August 5, 2016 8:34 PM
To: jjhe...@linux.vnet.ibm.com; libvir-list@redhat.com
Cc: Corey S. McQuay <csmcq...@linux.vnet.ibm.com>
Subject: [libvirt] [PATCH v1] qemu-migration: Disallow migration of
read only
disk

From: "Corey S. McQuay" <csmcq...@linux.vnet.ibm.com>

Currently Libvirt allows attempts to migrate read only disks. Qemu
cannot
handle this as read only disks cannot be written to on the
destination system.
The end result is a cryptic error message and a failed migration.

This patch causes migration to fail earlier and provides a meaningful
error
message stating that migrating read only disks is not supported.

What will happen if read-only disk is copied to destination prior to
migration start? Currently such scenario works, will it still work
with this code?

Based on our testing, pre-copying a read only disk image to the
destination system has no effect on the outcome of attempting to migrate
a non-shared read only disk. I'm not sure what scenario you are
referring to but here is what we tried:

Relevant guest xml:
 
   
   
   
   
   
   
   
 

The disk image exists at /disk-images/guest.iso on the source. Before
migration we copied the image to the same path on the destination
system. Then we attempted migration:

 virsh migrate --live --copy-storage-all --migrate-disks sdz
--verbose kvm1 qemu+ssh://dstHost/system tcp://dstHost

The error message we get is:

error: internal error: info migration reply was missing return status

Running journalctl shows additional information:

Aug 10 16:02:16 collin-kvm libvirtd[41616]: operation failed: migration
of disk sdz failed.

I'm pretty sure this patch does not stop the user from doing anything
that works today. But if your scenario is different from ours in some
way please let us know and we'll do some more testing.


Pawel,

Thanks for taking a look. Does Corey's reply address your concerns?

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

[libvirt] [PATCH] Libvirt: virTypedParamsValidate: Fix detection of multiple parameters

[Jason J. Herne]

virTypedParamsValidate currently uses an index based check to find
duplicate parameters. This check does not work. Consider the following
simple example:

We have only 2 keys
A  (multiples allowed)
B  (multiples NOT allowed)

We are given the following list of parameters to check:
A
A
B

If you work through the validation loop you will see that our last iteration
through the loop has i=2 and j=1. In this case, i > j and keys[j].value.i will
indicate that multiples are not allowed. Both conditionals are satisfied so
an incorrect error will be given: "parameter '%s' occurs multiple times"

This patch replaces the index based check with code that remembers
the name of the last parameter seen and only triggers the error case if
the current parameter name equals the last one. This works because the
list is sorted and duplicate parameters will be grouped together.

In reality, we hit this bug while using selective block migration to migrate
a guest with 5 disks. 5 was apparently just the right number to push i > j
and hit this bug.

virsh migrate --live guestname --copy-storage-all
  --migrate-disks vdb,vdc,vdd,vde,vdf
  qemu+ssh://dsthost/system

Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
Reviewed-by: Eric Farman <far...@linux.vnet.ibm.com>
---
 src/util/virtypedparam.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/util/virtypedparam.c b/src/util/virtypedparam.c
index 138fc64..23109e1 100644
--- a/src/util/virtypedparam.c
+++ b/src/util/virtypedparam.c
@@ -66,7 +66,7 @@ virTypedParamsValidate(virTypedParameterPtr params, int 
nparams, ...)
 va_list ap;
 int ret = -1;
 size_t i, j;
-const char *name;
+const char *name, *last_name = NULL;
 int type;
 size_t nkeys = 0, nkeysalloc = 0;
 virTypedParameterPtr sorted = NULL, keys = NULL;
@@ -106,7 +106,8 @@ virTypedParamsValidate(virTypedParameterPtr params, int 
nparams, ...)
 if (STRNEQ(sorted[i].field, keys[j].field)) {
 j++;
 } else {
-if (i > j && !(keys[j].value.i & VIR_TYPED_PARAM_MULTIPLE)) {
+if (STREQ_NULLABLE(last_name, sorted[i].field) &&
+!(keys[j].value.i & VIR_TYPED_PARAM_MULTIPLE)) {
 virReportError(VIR_ERR_INVALID_ARG,
_("parameter '%s' occurs multiple times"),
sorted[i].field);
@@ -125,6 +126,7 @@ virTypedParamsValidate(virTypedParameterPtr params, int 
nparams, ...)
virTypedParameterTypeToString(keys[j].type));
 goto cleanup;
 }
+last_name = sorted[i].field;
 i++;
 }
 }
-- 
1.9.1

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

[libvirt] [PATCH] Libvirt: Add missing default value for config option max_queued_clients

[Jason J. Herne]

Commit 1199edb1d4e3 added config option max_queued_clients and documented the
default value as 1000 but never actually set that value. This patch sets the
default value.

This addresses an issue whereby the following error message is reported if too
many migrations are started simultaneously:

error: End of file while reading data: Ncat: Invalid argument.: Input/output 
error

The problem is that too many ncat processes are spawned on the destination
system. They all attempt to connect to the libvirt socket. Because the
destination libvirtd cannot respond to the connect requests quickly enough we
overrun the socket's pending connections queue.

Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiu...@linux.vnet.ibm.com>
---
 daemon/libvirtd-config.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/daemon/libvirtd-config.c b/daemon/libvirtd-config.c
index c31c8b2..7a448f9 100644
--- a/daemon/libvirtd-config.c
+++ b/daemon/libvirtd-config.c
@@ -280,6 +280,7 @@ daemonConfigNew(bool privileged ATTRIBUTE_UNUSED)
 data->min_workers = 5;
 data->max_workers = 20;
 data->max_clients = 5000;
+data->max_queued_clients = 1000;
 data->max_anonymous_clients = 20;
 
 data->prio_workers = 5;
-- 
1.9.1

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

[libvirt] [PATCH] Fix libvirtd free() segfault when migrating guest with deleted open vswitch port

[Jason J. Herne]

libvirtd crashes on free()ing portData for an open vswitch port if that port
was deleted.  To reproduce:

ovs-vsctl del-port vnet0
virsh migrate --live kvm1 qemu+ssh://dstHost/system

Error message:
libvirtd: *** Error in `/usr/sbin/libvirtd': free(): invalid pointer: 
0x03ff90001e20 ***

The problem is that virCommandRun can return an empty string in the event that
the port being queried does not exist. When this happens then we are
unconditionally overwriting a newline character at position strlen()-1. When
strlen is 0, we overwrite memory that does not belong to the string.

The fix: Only overwrite the newline if the string is not empty.

Reviewed-by: Bjoern Walk <bw...@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com>
---
 src/util/virnetdevopenvswitch.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/util/virnetdevopenvswitch.c b/src/util/virnetdevopenvswitch.c
index 6780fb5..0f640d0 100644
--- a/src/util/virnetdevopenvswitch.c
+++ b/src/util/virnetdevopenvswitch.c
@@ -222,8 +222,10 @@ int virNetDevOpenvswitchGetMigrateData(char **migrate, 
const char *ifname)
 goto cleanup;
 }
 
-/* Wipeout the newline */
-(*migrate)[strlen(*migrate) - 1] = '\0';
+/* Wipeout the newline, if it exists */
+if (strlen(*migrate) > 0) {
+(*migrate)[strlen(*migrate) - 1] = '\0';
+}
 ret = 0;
  cleanup:
 virCommandFree(cmd);
-- 
1.9.1

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

Re: [libvirt] [PATCH] Fix reporting of i/o errors by iohelper process

[Jason J. Herne]

On 02/05/2015 11:26 AM, Jason J. Herne wrote:

Hello Eric,

it has been quite a while since we have looked at this :). I'm
revisiting this problem and I find that it still exists. Here is an
archive link of our previous discussions on this:

https://www.redhat.com/archives/libvir-list/2014-July/thread.html#00809

Basically, when I do a migration and run out of disk space I do not see
a meaningful error message without this patch. Early on in our previous
discussions you asked me how I had gotten through the
qemuDomainSaveMemory function without hitting this code:

if (virFileWrapperFdClose(wrapperFd)  0)
 goto cleanup;

If qemuMigrationToFile fails we go directly to cleanup and do not pass
through the virFileWrapperFdClose call. For reference:

 /* Perform the migration */
 if (qemuMigrationToFile(driver, vm, fd, offset, path,
 qemuCompressProgramName(compressed),
 bypassSecurityDriver,
 asyncJob)  0)
 goto cleanup;

This is why my patch adds the additional call to virFileWrapperFdClose.
Perhaps, if we cannot tolerate calling it twice, I can adjust the code
such that we only call it once.

For some odd reason, you seem to see messages that I do not (take look
at my final message in the thread linked above). I was not able to see
your goodbye world \n message.

I would be interested to know what you see when you run my test case
without my patch. If you feel like trying it just create a 50MB disk
image and loop mount it:

   mount -o loop /usr/local/var/lib/libvirt/qemu/save.img
/usr/local/var/lib/libvirt/qemu/save

Then:
 virsh managedsave guestname

And report what you saw on the command line and the libvirtd console
and/or log depending on how you run the daemon. I suspect (since you saw
goodbye world) that you would also see the out of disk space message
ok. If I'm correct, then the question becomes... why don't I see it too? :)

Thanks for your time.



Polite Ping? :)

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] [PATCH] Fix reporting of i/o errors by iohelper process

[Jason J. Herne]

Hello Eric,

it has been quite a while since we have looked at this :). I'm 
revisiting this problem and I find that it still exists. Here is an 
archive link of our previous discussions on this:


https://www.redhat.com/archives/libvir-list/2014-July/thread.html#00809

Basically, when I do a migration and run out of disk space I do not see 
a meaningful error message without this patch. Early on in our previous 
discussions you asked me how I had gotten through the 
qemuDomainSaveMemory function without hitting this code:


if (virFileWrapperFdClose(wrapperFd)  0)
goto cleanup;

If qemuMigrationToFile fails we go directly to cleanup and do not pass 
through the virFileWrapperFdClose call. For reference:


/* Perform the migration */
if (qemuMigrationToFile(driver, vm, fd, offset, path,
qemuCompressProgramName(compressed),
bypassSecurityDriver,
asyncJob)  0)
goto cleanup;

This is why my patch adds the additional call to virFileWrapperFdClose. 
Perhaps, if we cannot tolerate calling it twice, I can adjust the code 
such that we only call it once.


For some odd reason, you seem to see messages that I do not (take look 
at my final message in the thread linked above). I was not able to see 
your goodbye world \n message.


I would be interested to know what you see when you run my test case 
without my patch. If you feel like trying it just create a 50MB disk 
image and loop mount it:


  mount -o loop /usr/local/var/lib/libvirt/qemu/save.img 
/usr/local/var/lib/libvirt/qemu/save


Then:
virsh managedsave guestname

And report what you saw on the command line and the libvirtd console 
and/or log depending on how you run the daemon. I suspect (since you saw 
goodbye world) that you would also see the out of disk space message 
ok. If I'm correct, then the question becomes... why don't I see it too? :)


Thanks for your time.

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

[libvirt] [PATCH] Fix reporting of i/o errors by iohelper process

[Jason J. Herne]

From: Jason J. Herne jjhe...@us.ibm.com

libvirt_iohelper is a helper process that is exec'ed and used to handle I/O
during a Qemu managed save operation. Due to a missing call to
virFileWrapperFdClose, all I/O error messages reported by iohelper are lost.

This patch adds a call to virFileWrapperFdClose to the cleanup phase of
qemuDomainSaveMemory.

This patch also modifies virFileWrapperFdClose such that errors are only
reported when the length of the err_msg buffer is  0. Before now, the
existence of the buffer would trigger error reporting in virFileWrapperFdClose.

Signed-off-by: Jason J. Herne jjhe...@us.ibm.com
---
 src/qemu/qemu_driver.c | 1 +
 src/util/virfile.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index ecccf6c..8d78805 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -3015,6 +3015,7 @@ qemuDomainSaveMemory(virQEMUDriverPtr driver,
 
  cleanup:
 VIR_FORCE_CLOSE(fd);
+virFileWrapperFdClose(wrapperFd);
 virFileWrapperFdFree(wrapperFd);
 VIR_FREE(xml);
 
diff --git a/src/util/virfile.c b/src/util/virfile.c
index 463064c..813b4f5 100644
--- a/src/util/virfile.c
+++ b/src/util/virfile.c
@@ -322,7 +322,7 @@ virFileWrapperFdClose(virFileWrapperFdPtr wfd)
 return 0;
 
 ret = virCommandWait(wfd-cmd, NULL);
-if (wfd-err_msg)
+if (wfd-err_msg  strlen(wfd-err_msg))
 VIR_WARN(iohelper reports: %s, wfd-err_msg);
 
 return ret;
-- 
1.8.3.2

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

Re: [libvirt] Bug: iohelper drops I/O error messages

[Jason J. Herne]

On 06/24/2014 03:21 PM, Eric Blake wrote:

On 06/24/2014 08:07 AM, Jason J. Herne wrote:

During a recent managed save operation I received the following error
message:

  error: operation failed: domain save job: unexpectedly failed.

It turns out that I had run out of disk space. After a brief
investigation I
discovered that libvirt_iohelper is exec'ed and is used to handle all
I/O during
a (Qemu) managed save operation. While iohelper appears to be set up to log
error conditions when they occur, for some reason the logging is getting
lost.
I'm hoping someone can help figure out why these errors are getting
lost.


What version of libvirt are you using, in case it is something that has
been improved in the meantime?



I tried this again today with a recent version pulled from git. The 
following is the top commit.


commit b02fca79e858dc6e6d3209a44fe967f038ac6291
Date:   Wed Jul 9 10:57:33 2014 +0200

I'll take another look at the code. Hopefully I can figure out why the 
messages are getting lost.

Sorry for the delayed response.

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

[libvirt] Bug: iohelper drops I/O error messages

[Jason J. Herne]

During a recent managed save operation I received the following error
message:

 error: operation failed: domain save job: unexpectedly failed.

It turns out that I had run out of disk space. After a brief investigation I
discovered that libvirt_iohelper is exec'ed and is used to handle all 
I/O during

a (Qemu) managed save operation. While iohelper appears to be set up to log
error conditions when they occur, for some reason the logging is getting 
lost.

I'm hoping someone can help figure out why these errors are getting lost. It
would be nice to present a useful error message to the user when a 
managed save

fails because of an I/O error.

I was able to work around this problem with a patch that bypasses iohelper
entirely but I doubt that is really the best thing to do. Does anyone 
know why

these error messages are getting suppressed?

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

Re: [libvirt] Bug: iohelper drops I/O error messages

[Jason J. Herne]

On 05/20/2014 02:08 PM, Jason J. Herne wrote:

During a recent managed save operation I received the following error
message:

 error: operation failed: domain save job: unexpectedly failed.

It turns out that I had run out of disk space. After a brief
investigation I
discovered that libvirt_iohelper is exec'ed and is used to handle all
I/O during
a (Qemu) managed save operation. While iohelper appears to be set up to log
error conditions when they occur, for some reason the logging is getting
lost.
I'm hoping someone can help figure out why these errors are getting
lost. It
would be nice to present a useful error message to the user when a
managed save
fails because of an I/O error.



Ping? Anyone have any input on this? Not sure who the maintainer of 
iohelper is.


--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

[libvirt] [PATCH] Managed-Save: False warning on successful managed save restoration

[Jason J. Herne]

From: Jason J. Herne jjhe...@us.ibm.com

qemuDomainObjStart is checking the return code from qemuDomainObjRestore for
errors even after determining that the return code is 0. This causes the
following error message to appear even when the restore was successful.

Unable to restore from managed state [path]. Maybe the file is corrupted?

A simple conditional to handle the error case takes care of the problem.

Signed-off-by: Jason J. Herne jjhe...@us.ibm.com
---
 src/qemu/qemu_driver.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 2b852eb..cec2b6c 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -6081,14 +6081,15 @@ qemuDomainObjStart(virConnectPtr conn,
 else
 vm-hasManagedSave = false;
 }
-
-if (ret  0) {
-VIR_WARN(Ignoring incomplete managed state %s, managed_save);
-} else {
-VIR_WARN(Unable to restore from managed state %s. 
- Maybe the file is corrupted?, managed_save);
-goto cleanup;
+else {
+if (ret  0) {
+VIR_WARN(Ignoring incomplete managed state %s, 
managed_save);
+} else {
+VIR_WARN(Unable to restore from managed state %s. 
+ Maybe the file is corrupted?, managed_save);
+}
 }
+goto cleanup;
 }
 }
 
-- 
1.8.3.2

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

[libvirt] Bug: iohelper drops I/O error messages

[Jason J. Herne]

During a recent managed save operation I received the following error 
message:


error: operation failed: domain save job: unexpectedly failed.

It turns out that I had run out of disk space. After a brief investigation I
discovered that libvirt_iohelper is exec'ed and is used to handle all 
I/O during

a (Qemu) managed save operation. While iohelper appears to be set up to log
error conditions when they occur, for some reason the logging is getting 
lost.

I'm hoping someone can help figure out why these errors are getting lost. It
would be nice to present a useful error message to the user when a 
managed save

fails because of an I/O error.

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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