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@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 <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@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 (jjherne@linux.vnet.ibm.com)