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" <walling@xxxxxxxxxxxxxxxxxx>
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 <walling@xxxxxxxxxxxxxxxxxx>
Signed-off-by: Jason J. Herne <jjherne@xxxxxxxxxxxxxxxxxx>
---
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 (jjherne@xxxxxxxxxxxxxxxxxx)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list