[libvirt] [PowerPC Patch 0/4] Libvirt CPU enhancements for Power KVM
This patch series is a collection of enhancements for PowerPC CPUs on PowerKVM. Series Summary: ========== Patch 1/4 : Introduce a new architecture 'ppc64le' for libvirt. Patch 2/4 : Add libvirt support for VMs running in 'compat' mode on Power KVM. Patch 3/4 : Optimize PVR comparison for PowerPC CPUs. Patch 4/4 : Correctly model available CPUs in response to PowerPC QEMU implementation. Detail: ==== * PowerPC has traditionally been a Big-endian architecture. However, with PowerPC ISA version 2.07, it can run in Little-endian mode as well. IBM Power8 processors, compliant with ISA 2.07 allow launching VMs in little-endian mode. This is signified by 'ppc64le' architecture. Patch 1 adds this support to libvirt, to allow running VMs based on ppc64le architecture. * Patch 2-4 tweak libvirt to correctly model PowerPC CPUs based on recent PowerKVM implementation. PowerKVM permits VMs with vcpus in the following allowed modes : i) Host native mode: where the vcpu seen in the VM belongs to the same processor generation as the host. Example: A power8 host, conforming to PowerISA version 2.07, will run VMs with "power8" vcpus. ii) Binary Compatibility ("compat") mode: PowerISA allows processors to run VMs in binary compatibility ("compat") mode supporting an older version of ISA. As an example: In compatibility mode, a POWER8 host can run a "power7" VM conforming to PowerISA v2.06, while a POWER7 host can run a "power6" VM, conforming to power ISA v2.05. QEMU has recently added support to explicitly denote a VM running in compatibility mode through commits 6d9412ea & 8dfa3a5e85. Henceforth, VMs of type (i) will be invoked with the QEMU invocation "-cpu host", while VMs of type (ii) will be invoked using "-cpu host, compat=power6". Now, an explicit cpu selection using "-cpu POWER6" is moot, and the recommended practice is to use the matching compat mode, if the requested cpu type differs from the host. Patches 2-4 address various aspects of this change. * Patch 2 : Adds support for generating the correct command line for QEMU. New xml semantics are introduced to signify this type. * Patch 3 : PowerKVM vCPUs differ uniquely across generations ( such as power6, power7, power8). Each generation signifies a new PowerISA version that exhibits features unique to that generation. The higher order 16 bits of PVR denote the processor generation and the lower order 16 bits denote the cpu chip (sub)version. For all practical purposes of launching a VM, we care about the generation the vCPU will belong to, and not specifically the chip version. In fact, PowerKVM does not seek out specification of a unique chip version(such as POWER7_v2.3) for running a vCPU. This patch updates the libvirt PVR check to reflect this relationship. * Patch 4: As specified in QEMU commit 8dfa3a5e85, the supported modes for a "compat" CPU are power6/power7/power8. This patch amends cpu_map.xml to understand these modes. PPC64 CPU Test cases are also updated accordingly. This patch also includes a test case for compat mode, introduced in patch 2. Changelog: ====== Patch 1/4 : This is v1. Patch 2/4 : Rebased initial patch https://www.redhat.com/archives/libvir-list/2014-June/msg01338.html Patch 3/4, 4/4 : This is v2, addressing response https://www.redhat.com/archives/libvir-list/2014-August/msg00859.html -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India
From effd8cf666074b2299b58da40d618810ec0fe3ff Mon Sep 17 00:00:00 2001 From: "Pradipta Kr. Banerjee" <bpradip@in.ibm.com> Date: Tue, 7 Oct 2014 10:33:44 +0530
Starting PowerISA 2.07, Power architecture can run in little- endian mode as well. This adds support for PowerPC Little Endian architecture., and allows libvirt to spawn VMs in Little-Endian Mode. (conforming to 'ppc64le' architecture) Signed-off-by: Pradipta Kr. Banerjee <bpradip@in.ibm.com> Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> --- src/cpu/cpu_powerpc.c | 2 +- src/qemu/qemu_capabilities.c | 6 +++--- src/qemu/qemu_command.c | 22 +++++++++++----------- src/qemu/qemu_domain.c | 1 + src/util/virarch.h | 3 +++ 5 files changed, 19 insertions(+), 15 deletions(-) diff --git a/src/cpu/cpu_powerpc.c b/src/cpu/cpu_powerpc.c index 67cb9ff..d591c18 100644 --- a/src/cpu/cpu_powerpc.c +++ b/src/cpu/cpu_powerpc.c @@ -38,7 +38,7 @@ VIR_LOG_INIT("cpu.cpu_powerpc"); -static const virArch archs[] = { VIR_ARCH_PPC64 }; +static const virArch archs[] = { VIR_ARCH_PPC64, VIR_ARCH_PPC64LE }; struct ppc_vendor { char *name; diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 6fcb5c7..bb59a36 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -633,7 +633,7 @@ virQEMUCapsProbeCPUModels(virQEMUCapsPtr qemuCaps, uid_t runUid, gid_t runGid) if (qemuCaps->arch == VIR_ARCH_I686 || qemuCaps->arch == VIR_ARCH_X86_64) { parse = virQEMUCapsParseX86Models; - } else if (qemuCaps->arch == VIR_ARCH_PPC64) { + } else if ARCH_IS_PPC64(qemuCaps->arch) { parse = virQEMUCapsParsePPCModels; } else { VIR_DEBUG("don't know how to parse %s CPU models", @@ -2003,7 +2003,7 @@ bool virQEMUCapsHasPCIMultiBus(virQEMUCapsPtr qemuCaps, return true; if (def->os.arch == VIR_ARCH_PPC || - def->os.arch == VIR_ARCH_PPC64) { + ARCH_IS_PPC64(def->os.arch)) { /* * Usage of pci.0 naming: * @@ -3573,7 +3573,7 @@ virQEMUCapsSupportsChardev(virDomainDefPtr def, !virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE)) return false; - if ((def->os.arch == VIR_ARCH_PPC) || (def->os.arch == VIR_ARCH_PPC64)) { + if ((def->os.arch == VIR_ARCH_PPC) || ARCH_IS_PPC64(def->os.arch)) { /* only pseries need -device spapr-vty with -chardev */ return (chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL && chr->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO); diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 8cb0865..80ec9e8 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -713,7 +713,7 @@ qemuSetSCSIControllerModel(virDomainDefPtr def, return -1; } } else { - if ((def->os.arch == VIR_ARCH_PPC64) && + if (ARCH_IS_PPC64(def->os.arch) && STRPREFIX(def->os.machine, "pseries")) { *model = VIR_DOMAIN_CONTROLLER_MODEL_SCSI_IBMVSCSI; } else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_SCSI_LSI)) { @@ -1264,7 +1264,7 @@ int qemuDomainAssignSpaprVIOAddresses(virDomainDefPtr def, for (i = 0; i < def->nserials; i++) { if (def->serials[i]->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL && - (def->os.arch == VIR_ARCH_PPC64) && + ARCH_IS_PPC64(def->os.arch) && STRPREFIX(def->os.machine, "pseries")) def->serials[i]->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO; if (qemuAssignSpaprVIOAddress(def, &def->serials[i]->info, @@ -1273,7 +1273,7 @@ int qemuDomainAssignSpaprVIOAddresses(virDomainDefPtr def, } if (def->nvram) { - if (def->os.arch == VIR_ARCH_PPC64 && + if (ARCH_IS_PPC64(def->os.arch) && STRPREFIX(def->os.machine, "pseries")) def->nvram->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO; if (qemuAssignSpaprVIOAddress(def, &def->nvram->info, @@ -4195,7 +4195,7 @@ qemuBuildUSBControllerDevStr(virDomainDefPtr domainDef, model = def->model; if (model == -1) { - if (domainDef->os.arch == VIR_ARCH_PPC64) + if ARCH_IS_PPC64(domainDef->os.arch) model = VIR_DOMAIN_CONTROLLER_MODEL_USB_PCI_OHCI; else model = VIR_DOMAIN_CONTROLLER_MODEL_USB_PIIX3_UHCI; @@ -8562,7 +8562,7 @@ qemuBuildCommandLine(virConnectPtr conn, !qemuDomainMachineIsQ35(def) && (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_PIIX3_USB_UHCI) || (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_PCI_OHCI) && - def->os.arch == VIR_ARCH_PPC64))) { + ARCH_IS_PPC64(def->os.arch)))) { if (usblegacy) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("Multiple legacy USB controllers are " @@ -9760,7 +9760,7 @@ qemuBuildCommandLine(virConnectPtr conn, } if (def->nvram) { - if (def->os.arch == VIR_ARCH_PPC64 && + if (ARCH_IS_PPC64(def->os.arch) && STRPREFIX(def->os.machine, "pseries")) { if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_NVRAM)) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", @@ -9883,7 +9883,7 @@ qemuBuildSerialChrDeviceStr(char **deviceStr, { virBuffer cmd = VIR_BUFFER_INITIALIZER; - if ((arch == VIR_ARCH_PPC64) && STRPREFIX(machine, "pseries")) { + if (ARCH_IS_PPC64(arch) && STRPREFIX(machine, "pseries")) { if (serial->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL && serial->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO) { virBufferAsprintf(&cmd, "spapr-vty,chardev=char%s", @@ -10305,7 +10305,7 @@ qemuParseCommandLineDisk(virDomainXMLOptionPtr xmlopt, if (VIR_ALLOC(def->src) < 0) goto error; - if (((dom->os.arch == VIR_ARCH_PPC64) && + if ((ARCH_IS_PPC64(dom->os.arch) && dom->os.machine && STRPREFIX(dom->os.machine, "pseries"))) def->bus = VIR_DOMAIN_DISK_BUS_SCSI; else @@ -10398,7 +10398,7 @@ qemuParseCommandLineDisk(virDomainXMLOptionPtr xmlopt, } else if (STREQ(keywords[i], "if")) { if (STREQ(values[i], "ide")) { def->bus = VIR_DOMAIN_DISK_BUS_IDE; - if (((dom->os.arch == VIR_ARCH_PPC64) && + if ((ARCH_IS_PPC64(dom->os.arch) && dom->os.machine && STRPREFIX(dom->os.machine, "pseries"))) { virReportError(VIR_ERR_INTERNAL_ERROR, _("pseries systems do not support ide devices '%s'"), val); @@ -11643,7 +11643,7 @@ qemuParseCommandLine(virCapsPtr qemuCaps, } if (STREQ(arg, "-cdrom")) { disk->device = VIR_DOMAIN_DISK_DEVICE_CDROM; - if (((def->os.arch == VIR_ARCH_PPC64) && + if ((ARCH_IS_PPC64(def->os.arch) && def->os.machine && STRPREFIX(def->os.machine, "pseries"))) disk->bus = VIR_DOMAIN_DISK_BUS_SCSI; if (VIR_STRDUP(disk->dst, "hdc") < 0) @@ -11659,7 +11659,7 @@ qemuParseCommandLine(virCapsPtr qemuCaps, disk->bus = VIR_DOMAIN_DISK_BUS_IDE; else disk->bus = VIR_DOMAIN_DISK_BUS_SCSI; - if (((def->os.arch == VIR_ARCH_PPC64) && + if ((ARCH_IS_PPC64(def->os.arch) && def->os.machine && STRPREFIX(def->os.machine, "pseries"))) disk->bus = VIR_DOMAIN_DISK_BUS_SCSI; } diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 76fccce..e4edf34 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -980,6 +980,7 @@ qemuDomainDefPostParse(virDomainDefPtr def, break; case VIR_ARCH_PPC64: + case VIR_ARCH_PPC64LE: addPCIRoot = true; addDefaultUSBKBD = true; addDefaultUSBMouse = true; diff --git a/src/util/virarch.h b/src/util/virarch.h index d395e58..868e585 100644 --- a/src/util/virarch.h +++ b/src/util/virarch.h @@ -79,6 +79,9 @@ typedef enum { (arch) == VIR_ARCH_PPC64LE ||\ (arch) == VIR_ARCH_PPCEMB) +# define ARCH_IS_PPC64(arch) ((arch) == VIR_ARCH_PPC64 ||\ + (arch) == VIR_ARCH_PPC64LE) + # define ARCH_IS_ARM(arch) ((arch) == VIR_ARCH_ARMV6L ||\ (arch) == VIR_ARCH_ARMV7L ||\ (arch) == VIR_ARCH_ARMV7B ||\ -- 1.8.3.1 -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India
From 7228aacaa4b24907b1cbf33838ada8fb81890419 Mon Sep 17 00:00:00 2001 From: Prerna Saxena <prerna@linux.vnet.ibm.com> Date: Tue, 7 Oct 2014 10:53:08 +0530
PowerISA allows processors to run VMs in binary compatibility ("compat") mode supporting an older version of ISA. QEMU has recently added support to explicitly denote a VM running in compatibility mode through commit 6d9412ea & 8dfa3a5e85. Now, a "compat" mode VM can be run by invoking this qemu commandline on a POWER8 host: -cpu host,compat=power7. This patch allows libvirt to extend the "fallback" semantics of cpu model to describe this new mode for PowerKVM guests. As an example: When a user wants to request a power7 vm to run in compatibility mode on a Power8 host, this can be described in XML as follows : <cpu mode='custom' match='exact'> <model fallback='compat'>power7</model> </cpu> This has been introduced as a new mode since the behaviour of a guest in compat mode is different from running natively on an older PowerISA. Also, checks to cpuModelIsAllowed() have been removed, since QEMU for PowerKVM no longer supports specifying a non-host CPU model using '-cpu XXX'. Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Li Zhang <zhlcindy@linux.vnet.ibm.com> Signed-off-by: Pradipta Kr. Banerjee <bpradip@in.ibm.com> --- docs/schemas/domaincommon.rng | 1 + src/conf/cpu_conf.c | 3 ++- src/conf/cpu_conf.h | 1 + src/cpu/cpu_powerpc.c | 22 ++++------------------ src/qemu/qemu_command.c | 13 +++++++++++-- 5 files changed, 19 insertions(+), 21 deletions(-) diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 20d81ae..ebab482 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -4067,6 +4067,7 @@ <choice> <value>allow</value> <value>forbid</value> + <value>compat</value> </choice> </attribute> </optional> diff --git a/src/conf/cpu_conf.c b/src/conf/cpu_conf.c index 9b7fbb0..32fd54f 100644 --- a/src/conf/cpu_conf.c +++ b/src/conf/cpu_conf.c @@ -47,7 +47,8 @@ VIR_ENUM_IMPL(virCPUMatch, VIR_CPU_MATCH_LAST, VIR_ENUM_IMPL(virCPUFallback, VIR_CPU_FALLBACK_LAST, "allow", - "forbid") + "forbid", + "compat") VIR_ENUM_IMPL(virCPUFeaturePolicy, VIR_CPU_FEATURE_LAST, "force", diff --git a/src/conf/cpu_conf.h b/src/conf/cpu_conf.h index d45210b..69d8584 100644 --- a/src/conf/cpu_conf.h +++ b/src/conf/cpu_conf.h @@ -65,6 +65,7 @@ VIR_ENUM_DECL(virCPUMatch) typedef enum { VIR_CPU_FALLBACK_ALLOW, VIR_CPU_FALLBACK_FORBID, + VIR_CPU_FALLBACK_COMPAT, VIR_CPU_FALLBACK_LAST } virCPUFallback; diff --git a/src/cpu/cpu_powerpc.c b/src/cpu/cpu_powerpc.c index d591c18..9ab33c2 100644 --- a/src/cpu/cpu_powerpc.c +++ b/src/cpu/cpu_powerpc.c @@ -458,8 +458,8 @@ ppcCompare(virCPUDefPtr host, static int ppcDecode(virCPUDefPtr cpu, const virCPUData *data, - const char **models, - unsigned int nmodels, + const char **models ATTRIBUTE_UNUSED, + unsigned int nmodels ATTRIBUTE_UNUSED, const char *preferred ATTRIBUTE_UNUSED, unsigned int flags) { @@ -479,13 +479,6 @@ ppcDecode(virCPUDefPtr cpu, goto cleanup; } - if (!cpuModelIsAllowed(model->name, models, nmodels)) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - _("CPU model %s is not supported by hypervisor"), - model->name); - goto cleanup; - } - if (VIR_STRDUP(cpu->model, model->name) < 0 || (model->vendor && VIR_STRDUP(cpu->vendor, model->vendor->name) < 0)) { goto cleanup; @@ -562,8 +555,8 @@ ppcUpdate(virCPUDefPtr guest, static virCPUDefPtr ppcBaseline(virCPUDefPtr *cpus, unsigned int ncpus, - const char **models, - unsigned int nmodels, + const char **models ATTRIBUTE_UNUSED, + unsigned int nmodels ATTRIBUTE_UNUSED, unsigned int flags) { struct ppc_map *map = NULL; @@ -583,13 +576,6 @@ ppcBaseline(virCPUDefPtr *cpus, goto error; } - if (!cpuModelIsAllowed(model->name, models, nmodels)) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - _("CPU model %s is not supported by hypervisor"), - model->name); - goto error; - } - for (i = 0; i < ncpus; i++) { const struct ppc_vendor *vnd; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 80ec9e8..74dc9d2 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -6221,7 +6221,9 @@ qemuBuildCpuModelArgStr(virQEMUDriverPtr driver, *hasHwVirt = hasSVM > 0 ? true : false; } - if (cpu->mode == VIR_CPU_MODE_HOST_PASSTHROUGH) { + if ((cpu->mode == VIR_CPU_MODE_HOST_PASSTHROUGH) || + ((cpu->mode == VIR_CPU_MODE_HOST_MODEL) && + ARCH_IS_PPC64(def->os.arch))) { const char *mode = virCPUModeTypeToString(cpu->mode); if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_CPU_HOST)) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, @@ -6260,7 +6262,14 @@ qemuBuildCpuModelArgStr(virQEMUDriverPtr driver, goto cleanup; } - virBufferAdd(buf, guest->model, -1); + if (ARCH_IS_PPC64(def->os.arch) && + cpu->fallback == VIR_CPU_FALLBACK_COMPAT) { + virBufferAddLit(buf, "host"); + virBufferAsprintf(buf, ",compat=%s", guest->model); + } else { + virBufferAdd(buf, guest->model, -1); + } + if (guest->vendor_id) virBufferAsprintf(buf, ",vendor=%s", guest->vendor_id); for (i = 0; i < guest->nfeatures; i++) { -- 1.8.3.1 -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India
On Fri, Oct 10, 2014 at 03:42:41PM +0530, Prerna Saxena wrote:
From 7228aacaa4b24907b1cbf33838ada8fb81890419 Mon Sep 17 00:00:00 2001 From: Prerna Saxena <prerna@linux.vnet.ibm.com> Date: Tue, 7 Oct 2014 10:53:08 +0530
PowerISA allows processors to run VMs in binary compatibility ("compat") mode supporting an older version of ISA. QEMU has recently added support to explicitly denote a VM running in compatibility mode through commit 6d9412ea & 8dfa3a5e85. Now, a "compat" mode VM can be run by invoking this qemu commandline on a POWER8 host: -cpu host,compat=power7.
If this is using 'host'
This patch allows libvirt to extend the "fallback" semantics of cpu model to describe this new mode for PowerKVM guests. As an example: When a user wants to request a power7 vm to run in compatibility mode on a Power8 host, this can be described in XML as follows : <cpu mode='custom' match='exact'> <model fallback='compat'>power7</model> </cpu>
Then I don't think this should be using mode='custom', but rather it should be 'host-passthrough'. We would use the <model> to denote the compatibility mode for the host passthrough. IOW, it feels like this is better described as <cpu mode='host-passthrough' match='exact'> <model>power7</model> </cpu> Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Friday 10 October 2014 03:46 PM, Daniel P. Berrange wrote:
On Fri, Oct 10, 2014 at 03:42:41PM +0530, Prerna Saxena wrote:
From 7228aacaa4b24907b1cbf33838ada8fb81890419 Mon Sep 17 00:00:00 2001 From: Prerna Saxena <prerna@linux.vnet.ibm.com> Date: Tue, 7 Oct 2014 10:53:08 +0530
PowerISA allows processors to run VMs in binary compatibility ("compat") mode supporting an older version of ISA. QEMU has recently added support to explicitly denote a VM running in compatibility mode through commit 6d9412ea & 8dfa3a5e85. Now, a "compat" mode VM can be run by invoking this qemu commandline on a POWER8 host: -cpu host,compat=power7. If this is using 'host'
This patch allows libvirt to extend the "fallback" semantics of cpu model to describe this new mode for PowerKVM guests. As an example: When a user wants to request a power7 vm to run in compatibility mode on a Power8 host, this can be described in XML as follows : <cpu mode='custom' match='exact'> <model fallback='compat'>power7</model> </cpu> Then I don't think this should be using mode='custom', but rather it should be 'host-passthrough'. We would use the <model> to denote the compatibility mode for the host passthrough. IOW, it feels like this is better described as
<cpu mode='host-passthrough' match='exact'> <model>power7</model> </cpu> Hi Daniel, Thanks for taking a look. It appears that my example didnt bring out the use case very clearly.
On PowerKVM, we can run VMs in 2 possible vCPU configurations: 1) Host native mode: Where host is power7; guest VMs also see power7 vcpus.. Required qemu command line : "-cpu host" You correctly pointed out that this would use <cpu mode='host-passthrough'.> 2) Compat mode: In this case, the host CPU is power7, but it can run in binary compatibility mode with an older version of ISA(such as power6). So it will exhibit only those features that were available in an older generation of Power ISA. The guest will see a "power6" vCPU even though it is running on a physical "power7" chip. Required QEMU command line for PowerKVM : "-cpu host,compat=power6" My patch attempts to define semantics for this mode of execution. <cpu mode='custom' match='exact'> <model fallback='compat'>power7</model> </cpu> I came up with this ^^^ XML schema to denote a compat mode guest. Looking for community feedback / suggestions on how this can best be brought out in libvirt XML schema. regards -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India
On Fri, Oct 10, 2014 at 04:12:26PM +0530, Prerna Saxena wrote:
On Friday 10 October 2014 03:46 PM, Daniel P. Berrange wrote:
On Fri, Oct 10, 2014 at 03:42:41PM +0530, Prerna Saxena wrote:
From 7228aacaa4b24907b1cbf33838ada8fb81890419 Mon Sep 17 00:00:00 2001 From: Prerna Saxena <prerna@linux.vnet.ibm.com> Date: Tue, 7 Oct 2014 10:53:08 +0530
PowerISA allows processors to run VMs in binary compatibility ("compat") mode supporting an older version of ISA. QEMU has recently added support to explicitly denote a VM running in compatibility mode through commit 6d9412ea & 8dfa3a5e85. Now, a "compat" mode VM can be run by invoking this qemu commandline on a POWER8 host: -cpu host,compat=power7. If this is using 'host'
This patch allows libvirt to extend the "fallback" semantics of cpu model to describe this new mode for PowerKVM guests. As an example: When a user wants to request a power7 vm to run in compatibility mode on a Power8 host, this can be described in XML as follows : <cpu mode='custom' match='exact'> <model fallback='compat'>power7</model> </cpu> Then I don't think this should be using mode='custom', but rather it should be 'host-passthrough'. We would use the <model> to denote the compatibility mode for the host passthrough. IOW, it feels like this is better described as
<cpu mode='host-passthrough' match='exact'> <model>power7</model> </cpu> Hi Daniel, Thanks for taking a look. It appears that my example didnt bring out the use case very clearly.
On PowerKVM, we can run VMs in 2 possible vCPU configurations: 1) Host native mode: Where host is power7; guest VMs also see power7 vcpus.. Required qemu command line : "-cpu host" You correctly pointed out that this would use <cpu mode='host-passthrough'.>
2) Compat mode: In this case, the host CPU is power7, but it can run in binary compatibility mode with an older version of ISA(such as power6). So it will exhibit only those features that were available in an older generation of Power ISA. The guest will see a "power6" vCPU even though it is running on a physical "power7" chip. Required QEMU command line for PowerKVM : "-cpu host,compat=power6"
My patch attempts to define semantics for this mode of execution.
<cpu mode='custom' match='exact'> <model fallback='compat'>power7</model> </cpu>
I came up with this ^^^ XML schema to denote a compat mode guest.
The CPU mode 'host' is a form of host CPU passthrough. ie Running '-cpu host,compat=power6' on a Power7 host is equivalent to running '-cpu host' on a Power6 host. So IMHO that should still use mode='host-passthrough' in libvirt not mode=custom Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Friday 10 October 2014 04:41 PM, Daniel P. Berrange wrote:
On Fri, Oct 10, 2014 at 04:12:26PM +0530, Prerna Saxena wrote:
On Friday 10 October 2014 03:46 PM, Daniel P. Berrange wrote:
On Fri, Oct 10, 2014 at 03:42:41PM +0530, Prerna Saxena wrote:
From 7228aacaa4b24907b1cbf33838ada8fb81890419 Mon Sep 17 00:00:00 2001 From: Prerna Saxena <prerna@linux.vnet.ibm.com> Date: Tue, 7 Oct 2014 10:53:08 +0530
PowerISA allows processors to run VMs in binary compatibility ("compat") mode supporting an older version of ISA. QEMU has recently added support to explicitly denote a VM running in compatibility mode through commit 6d9412ea & 8dfa3a5e85. Now, a "compat" mode VM can be run by invoking this qemu commandline on a POWER8 host: -cpu host,compat=power7. If this is using 'host'
This patch allows libvirt to extend the "fallback" semantics of cpu model to describe this new mode for PowerKVM guests. As an example: When a user wants to request a power7 vm to run in compatibility mode on a Power8 host, this can be described in XML as follows : <cpu mode='custom' match='exact'> <model fallback='compat'>power7</model> </cpu> Then I don't think this should be using mode='custom', but rather it should be 'host-passthrough'. We would use the <model> to denote the compatibility mode for the host passthrough. IOW, it feels like this is better described as
<cpu mode='host-passthrough' match='exact'> <model>power7</model> </cpu> Hi Daniel, Thanks for taking a look. It appears that my example didnt bring out the use case very clearly.
On PowerKVM, we can run VMs in 2 possible vCPU configurations: 1) Host native mode: Where host is power7; guest VMs also see power7 vcpus.. Required qemu command line : "-cpu host" You correctly pointed out that this would use <cpu mode='host-passthrough'.>
2) Compat mode: In this case, the host CPU is power7, but it can run in binary compatibility mode with an older version of ISA(such as power6). So it will exhibit only those features that were available in an older generation of Power ISA. The guest will see a "power6" vCPU even though it is running on a physical "power7" chip. Required QEMU command line for PowerKVM : "-cpu host,compat=power6"
My patch attempts to define semantics for this mode of execution.
<cpu mode='custom' match='exact'> <model fallback='compat'>power7</model> </cpu>
I came up with this ^^^ XML schema to denote a compat mode guest. The CPU mode 'host' is a form of host CPU passthrough. ie Running '-cpu host,compat=power6' on a Power7 host is equivalent to running '-cpu host' on a Power6 host. It exposes the same features as an older version. However, running 'compat' on Power7 isnt identical as running native on Power6.
So IMHO that should still use mode='host-passthrough' in libvirt not mode=custom
Okay. Do you mean it should be listed in XML like this : <cpu mode='host-passthrough' match='exact'> <model fallback='compat'>power6</model> </cpu> I'll send a v2 in this format. -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India
From 1bcba78ed387a876208fec1ef60b81d65c8474e5 Mon Sep 17 00:00:00 2001 From: "Pradipta Kr. Banerjee" <bpradip@in.ibm.com> Date: Tue, 7 Oct 2014 11:12:36 +0530
IBM Power processors differ uniquely across generations (such as power6, power7, power8). Each generation signifies a new PowerISA version that exhibits features unique to that generation. The higher 16 bits of PVR for IBM Power processors encode the CPU generation, while the CPU chip (sub)version is encoded in lower 16 bits. For all practical purposes of launching a VM, we care about the generation which the vCPU will belong to, and not specifically the chip version. This patch updates the libvirt PVR check to reflect this relationship. It also contains changes to cpu_map.xml since processor generations as understood by QEMU compat mode go as "power6", "power7" or "power8" [Reference : QEMU commit 8dfa3a5e85 ] Signed-off-by: Pradipta Kr. Banerjee <bpradip@in.ibm.com> Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> --- src/cpu/cpu_map.xml | 22 ++++++++-------------- src/cpu/cpu_powerpc.c | 7 ++++++- 2 files changed, 14 insertions(+), 15 deletions(-) diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 18c7b0d..f2f13fb 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -602,30 +602,24 @@ <vendor name='IBM'/> <!-- IBM-based CPU models --> - <model name='POWER7'> + <model name='power6'> <vendor name='IBM'/> - <pvr value='0x003f0200'/> + <pvr value='0x003e0000'/> </model> - <model name='POWER7_v2.1'> + <model name='power7'> <vendor name='IBM'/> - <pvr value='0x003f0201'/> + <pvr value='0x003f0000'/> </model> - <model name='POWER7_v2.3'> + <model name='power7+'> <vendor name='IBM'/> - <pvr value='0x003f0203'/> + <pvr value='0x004a0000'/> </model> - <model name='POWER7+_v2.1'> + <model name='power8'> <vendor name='IBM'/> - <pvr value='0x004a0201'/> + <pvr value='0x004b0000'/> </model> - - <model name='POWER8_v1.0'> - <vendor name='IBM'/> - <pvr value='0x004b0100'/> - </model> - </arch> </cpus> diff --git a/src/cpu/cpu_powerpc.c b/src/cpu/cpu_powerpc.c index 9ab33c2..ddca0d4 100644 --- a/src/cpu/cpu_powerpc.c +++ b/src/cpu/cpu_powerpc.c @@ -93,7 +93,12 @@ ppcModelFindPVR(const struct ppc_map *map, model = map->models; while (model != NULL) { - if (model->data.pvr == pvr) + /*IBM PowerPC processors encode PVR as CPU family in higher 16 bits and + *a CPU version in lower 16 bits. Since there is no significant change + *in behavior between versions, there is no point to add every single CPU + *version in cpu_map.xml + */ + if ((model->data.pvr & 0xFFFF0000) == (pvr & 0xFFFF0000)) return model; model = model->next; -- 1.8.3.1 -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India
On Fri, Oct 10, 2014 at 03:51:22PM +0530, Prerna Saxena wrote:
From 1bcba78ed387a876208fec1ef60b81d65c8474e5 Mon Sep 17 00:00:00 2001 From: "Pradipta Kr. Banerjee" <bpradip@in.ibm.com> Date: Tue, 7 Oct 2014 11:12:36 +0530
IBM Power processors differ uniquely across generations (such as power6, power7, power8). Each generation signifies a new PowerISA version that exhibits features unique to that generation. The higher 16 bits of PVR for IBM Power processors encode the CPU generation, while the CPU chip (sub)version is encoded in lower 16 bits.
For all practical purposes of launching a VM, we care about the generation which the vCPU will belong to, and not specifically the chip version. This patch updates the libvirt PVR check to reflect this relationship. It also contains changes to cpu_map.xml since processor generations as understood by QEMU compat mode go as "power6", "power7" or "power8" [Reference : QEMU commit 8dfa3a5e85 ]
Signed-off-by: Pradipta Kr. Banerjee <bpradip@in.ibm.com> Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> --- src/cpu/cpu_map.xml | 22 ++++++++-------------- src/cpu/cpu_powerpc.c | 7 ++++++- 2 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 18c7b0d..f2f13fb 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -602,30 +602,24 @@ <vendor name='IBM'/>
<!-- IBM-based CPU models --> - <model name='POWER7'> + <model name='power6'> <vendor name='IBM'/> - <pvr value='0x003f0200'/> + <pvr value='0x003e0000'/> </model>
- <model name='POWER7_v2.1'> + <model name='power7'> <vendor name='IBM'/> - <pvr value='0x003f0201'/> + <pvr value='0x003f0000'/> </model>
- <model name='POWER7_v2.3'> + <model name='power7+'> <vendor name='IBM'/> - <pvr value='0x003f0203'/> + <pvr value='0x004a0000'/> </model>
- <model name='POWER7+_v2.1'> + <model name='power8'> <vendor name='IBM'/> - <pvr value='0x004a0201'/> + <pvr value='0x004b0000'/> </model> - - <model name='POWER8_v1.0'> - <vendor name='IBM'/> - <pvr value='0x004b0100'/> - </model> - </arch> </cpus>
This looks like it is going to break upgrades for any existing deployed guests on PPC using named CPU models, which is not something we can do. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Friday 10 October 2014 03:55 PM, Daniel P. Berrange wrote:
On Fri, Oct 10, 2014 at 03:51:22PM +0530, Prerna Saxena wrote:
From 1bcba78ed387a876208fec1ef60b81d65c8474e5 Mon Sep 17 00:00:00 2001 From: "Pradipta Kr. Banerjee" <bpradip@in.ibm.com> Date: Tue, 7 Oct 2014 11:12:36 +0530
IBM Power processors differ uniquely across generations (such as power6, power7, power8). Each generation signifies a new PowerISA version that exhibits features unique to that generation. The higher 16 bits of PVR for IBM Power processors encode the CPU generation, while the CPU chip (sub)version is encoded in lower 16 bits.
For all practical purposes of launching a VM, we care about the generation which the vCPU will belong to, and not specifically the chip version. This patch updates the libvirt PVR check to reflect this relationship. It also contains changes to cpu_map.xml since processor generations as understood by QEMU compat mode go as "power6", "power7" or "power8" [Reference : QEMU commit 8dfa3a5e85 ]
Signed-off-by: Pradipta Kr. Banerjee <bpradip@in.ibm.com> Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> --- src/cpu/cpu_map.xml | 22 ++++++++-------------- src/cpu/cpu_powerpc.c | 7 ++++++- 2 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 18c7b0d..f2f13fb 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -602,30 +602,24 @@ <vendor name='IBM'/>
<!-- IBM-based CPU models --> - <model name='POWER7'> + <model name='power6'> <vendor name='IBM'/> - <pvr value='0x003f0200'/> + <pvr value='0x003e0000'/> </model>
- <model name='POWER7_v2.1'> + <model name='power7'> <vendor name='IBM'/> - <pvr value='0x003f0201'/> + <pvr value='0x003f0000'/> </model>
- <model name='POWER7_v2.3'> + <model name='power7+'> <vendor name='IBM'/> - <pvr value='0x003f0203'/> + <pvr value='0x004a0000'/> </model>
- <model name='POWER7+_v2.1'> + <model name='power8'> <vendor name='IBM'/> - <pvr value='0x004a0201'/> + <pvr value='0x004b0000'/> </model> - - <model name='POWER8_v1.0'> - <vendor name='IBM'/> - <pvr value='0x004b0100'/> - </model> - </arch> </cpus>
This looks like it is going to break upgrades for any existing deployed guests on PPC using named CPU models, which is not something we can do.
Hmm, if I let this be, it will break compatibility mode support introduced in QEMU commit 8dfa3a5e85. Would it make sense to add a new entry for each PowerPC CPU generation in cpu_map.xml ? Each generation will be distinguished from regular models by PVR-- each of such entries will have lower 16 bits zero'ed. Something like : <model name='power8'> <vendor name='IBM'/> <pvr value='0x004b0000'/> </model> Does that look reasonable ? I'll spin a patch to that end if it does ? -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India
On Fri, Oct 10, 2014 at 04:27:07PM +0530, Prerna Saxena wrote:
On Friday 10 October 2014 03:55 PM, Daniel P. Berrange wrote:
On Fri, Oct 10, 2014 at 03:51:22PM +0530, Prerna Saxena wrote:
From 1bcba78ed387a876208fec1ef60b81d65c8474e5 Mon Sep 17 00:00:00 2001 From: "Pradipta Kr. Banerjee" <bpradip@in.ibm.com> Date: Tue, 7 Oct 2014 11:12:36 +0530
IBM Power processors differ uniquely across generations (such as power6, power7, power8). Each generation signifies a new PowerISA version that exhibits features unique to that generation. The higher 16 bits of PVR for IBM Power processors encode the CPU generation, while the CPU chip (sub)version is encoded in lower 16 bits.
For all practical purposes of launching a VM, we care about the generation which the vCPU will belong to, and not specifically the chip version. This patch updates the libvirt PVR check to reflect this relationship. It also contains changes to cpu_map.xml since processor generations as understood by QEMU compat mode go as "power6", "power7" or "power8" [Reference : QEMU commit 8dfa3a5e85 ]
Signed-off-by: Pradipta Kr. Banerjee <bpradip@in.ibm.com> Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> --- src/cpu/cpu_map.xml | 22 ++++++++-------------- src/cpu/cpu_powerpc.c | 7 ++++++- 2 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 18c7b0d..f2f13fb 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -602,30 +602,24 @@ <vendor name='IBM'/>
<!-- IBM-based CPU models --> - <model name='POWER7'> + <model name='power6'> <vendor name='IBM'/> - <pvr value='0x003f0200'/> + <pvr value='0x003e0000'/> </model>
- <model name='POWER7_v2.1'> + <model name='power7'> <vendor name='IBM'/> - <pvr value='0x003f0201'/> + <pvr value='0x003f0000'/> </model>
- <model name='POWER7_v2.3'> + <model name='power7+'> <vendor name='IBM'/> - <pvr value='0x003f0203'/> + <pvr value='0x004a0000'/> </model>
- <model name='POWER7+_v2.1'> + <model name='power8'> <vendor name='IBM'/> - <pvr value='0x004a0201'/> + <pvr value='0x004b0000'/> </model> - - <model name='POWER8_v1.0'> - <vendor name='IBM'/> - <pvr value='0x004b0100'/> - </model> - </arch> </cpus>
This looks like it is going to break upgrades for any existing deployed guests on PPC using named CPU models, which is not something we can do.
Hmm, if I let this be, it will break compatibility mode support introduced in QEMU commit 8dfa3a5e85. Would it make sense to add a new entry for each PowerPC CPU generation in cpu_map.xml ? Each generation will be distinguished from regular models by PVR-- each of such entries will have lower 16 bits zero'ed.
Something like : <model name='power8'> <vendor name='IBM'/> <pvr value='0x004b0000'/> </model>
Does that look reasonable ?
I don't really know what the PVF values mean. From the POV of libvirt though the key requirement is that existing deployed guests must not see *any* change in the features exposed in their CPU if their XML does not change, and we must retain compat with existing XML configs. So you can only add more CPUs, you cannot change existing CPUs. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Friday 10 October 2014 04:38 PM, Daniel P. Berrange wrote:
On Friday 10 October 2014 03:55 PM, Daniel P. Berrange wrote:
On Fri, Oct 10, 2014 at 03:51:22PM +0530, Prerna Saxena wrote:
From 1bcba78ed387a876208fec1ef60b81d65c8474e5 Mon Sep 17 00:00:00 2001 From: "Pradipta Kr. Banerjee" <bpradip@in.ibm.com> Date: Tue, 7 Oct 2014 11:12:36 +0530
IBM Power processors differ uniquely across generations (such as power6, power7, power8). Each generation signifies a new PowerISA version that exhibits features unique to that generation. The higher 16 bits of PVR for IBM Power processors encode the CPU generation, while the CPU chip (sub)version is encoded in lower 16 bits.
For all practical purposes of launching a VM, we care about the generation which the vCPU will belong to, and not specifically the chip version. This patch updates the libvirt PVR check to reflect this relationship. It also contains changes to cpu_map.xml since processor generations as understood by QEMU compat mode go as "power6", "power7" or "power8" [Reference : QEMU commit 8dfa3a5e85 ]
Signed-off-by: Pradipta Kr. Banerjee <bpradip@in.ibm.com> Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> --- src/cpu/cpu_map.xml | 22 ++++++++-------------- src/cpu/cpu_powerpc.c | 7 ++++++- 2 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 18c7b0d..f2f13fb 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -602,30 +602,24 @@ <vendor name='IBM'/>
<!-- IBM-based CPU models --> - <model name='POWER7'> + <model name='power6'> <vendor name='IBM'/> - <pvr value='0x003f0200'/> + <pvr value='0x003e0000'/> </model>
- <model name='POWER7_v2.1'> + <model name='power7'> <vendor name='IBM'/> - <pvr value='0x003f0201'/> + <pvr value='0x003f0000'/> </model>
- <model name='POWER7_v2.3'> + <model name='power7+'> <vendor name='IBM'/> - <pvr value='0x003f0203'/> + <pvr value='0x004a0000'/> </model>
- <model name='POWER7+_v2.1'> + <model name='power8'> <vendor name='IBM'/> - <pvr value='0x004a0201'/> + <pvr value='0x004b0000'/> </model> - - <model name='POWER8_v1.0'> - <vendor name='IBM'/> - <pvr value='0x004b0100'/> - </model> - </arch> </cpus> This looks like it is going to break upgrades for any existing deployed guests on PPC using named CPU models, which is not something we can do.
Hmm, if I let this be, it will break compatibility mode support introduced in QEMU commit 8dfa3a5e85. Would it make sense to add a new entry for each PowerPC CPU generation in cpu_map.xml ? Each generation will be distinguished from regular models by PVR-- each of such entries will have lower 16 bits zero'ed.
Something like : <model name='power8'> <vendor name='IBM'/> <pvr value='0x004b0000'/> </model>
Does that look reasonable ? I don't really know what the PVF values mean. From the POV of libvirt
On Fri, Oct 10, 2014 at 04:27:07PM +0530, Prerna Saxena wrote: though the key requirement is that existing deployed guests must not see *any* change in the features exposed in their CPU if their XML does not change, and we must retain compat with existing XML configs.
So you can only add more CPUs, you cannot change existing CPUs.
Regards, Daniel Thanks for the tip! I understand your perspective. I'll send out a v2 which will respect this requirement.
-- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India
From 67ca1c61d5e1c7de0c2d44e2ef47bc8bba39c159 Mon Sep 17 00:00:00 2001 From: "Pradipta Kr. Banerjee" <bpradip@in.ibm.com> Date: Tue, 7 Oct 2014 13:38:28 +0530
With reference to the previous update of cpu_map.xml, this patch fixes test cases for PowerPC CPUs. This also updates a test case for compat mode, introduced previously in the series. Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Pradipta Kr. Banerjee <bpradip@in.ibm.com> Signed-off-by: Li Zhang <zhlcindy@linux.vnet.ibm.com> --- tests/cputest.c | 4 ++-- tests/cputestdata/ppc64-baseline-1-result.xml | 2 +- tests/cputestdata/ppc64-baseline-incompatible-vendors.xml | 4 ++-- tests/cputestdata/ppc64-baseline-no-vendor-result.xml | 2 +- tests/cputestdata/ppc64-baseline-no-vendor.xml | 2 +- tests/cputestdata/ppc64-exact.xml | 2 +- tests/cputestdata/ppc64-guest-nofallback.xml | 2 +- tests/cputestdata/ppc64-guest.xml | 2 +- tests/cputestdata/ppc64-host+guest,ppc_models-result.xml | 2 +- .../ppc64-host+guest-nofallback,ppc_models,POWER7_v2.1-result.xml | 5 ----- .../ppc64-host+guest-nofallback,ppc_models,power7-result.xml | 5 +++++ tests/cputestdata/ppc64-host.xml | 2 +- tests/cputestdata/ppc64-strict.xml | 2 +- tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.args | 3 ++- tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.xml | 2 +- 15 files changed, 21 insertions(+), 20 deletions(-) delete mode 100644 tests/cputestdata/ppc64-host+guest-nofallback,ppc_models,POWER7_v2.1-result.xml create mode 100644 tests/cputestdata/ppc64-host+guest-nofallback,ppc_models,power7-result.xml diff --git a/tests/cputest.c b/tests/cputest.c index a507576..96b9dbf 100644 --- a/tests/cputest.c +++ b/tests/cputest.c @@ -496,7 +496,7 @@ cpuTestRun(const char *name, const struct data *data) static const char *model486[] = { "486" }; static const char *nomodel[] = { "nomodel" }; static const char *models[] = { "qemu64", "core2duo", "Nehalem" }; -static const char *ppc_models[] = { "POWER7", "POWER7_v2.1", "POWER8_v1.0"}; +static const char *ppc_models[] = { "power6", "power7", "power8"}; static int mymain(void) @@ -643,7 +643,7 @@ mymain(void) models, "Penryn", -1); DO_TEST_GUESTDATA("ppc64", "host", "guest", ppc_models, NULL, 0); - DO_TEST_GUESTDATA("ppc64", "host", "guest-nofallback", ppc_models, "POWER7_v2.1", -1); + DO_TEST_GUESTDATA("ppc64", "host", "guest-nofallback", ppc_models, "power7", -1); return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE; } diff --git a/tests/cputestdata/ppc64-baseline-1-result.xml b/tests/cputestdata/ppc64-baseline-1-result.xml index cbdd9bc..a330ef6 100644 --- a/tests/cputestdata/ppc64-baseline-1-result.xml +++ b/tests/cputestdata/ppc64-baseline-1-result.xml @@ -1,3 +1,3 @@ <cpu mode='custom' match='exact'> - <model fallback='allow'>POWER7+_v2.1</model> + <model fallback='allow'>power7</model> </cpu> diff --git a/tests/cputestdata/ppc64-baseline-incompatible-vendors.xml b/tests/cputestdata/ppc64-baseline-incompatible-vendors.xml index 97d3c9c..10059c6 100644 --- a/tests/cputestdata/ppc64-baseline-incompatible-vendors.xml +++ b/tests/cputestdata/ppc64-baseline-incompatible-vendors.xml @@ -1,13 +1,13 @@ <cpuTest> <cpu> <arch>ppc64</arch> - <model>POWER7+_v2.1</model> + <model>power7</model> <vendor>Intel</vendor> <topology sockets='2' cores='4' threads='1'/> </cpu> <cpu> <arch>ppc64</arch> - <model>POWER8_v1.0</model> + <model>power8</model> <vendor>Intel</vendor> <topology sockets='1' cores='1' threads='1'/> </cpu> diff --git a/tests/cputestdata/ppc64-baseline-no-vendor-result.xml b/tests/cputestdata/ppc64-baseline-no-vendor-result.xml index 36bae52..a330ef6 100644 --- a/tests/cputestdata/ppc64-baseline-no-vendor-result.xml +++ b/tests/cputestdata/ppc64-baseline-no-vendor-result.xml @@ -1,3 +1,3 @@ <cpu mode='custom' match='exact'> - <model fallback='allow'>POWER7_v2.3</model> + <model fallback='allow'>power7</model> </cpu> diff --git a/tests/cputestdata/ppc64-baseline-no-vendor.xml b/tests/cputestdata/ppc64-baseline-no-vendor.xml index 5e69a62..6b88977 100644 --- a/tests/cputestdata/ppc64-baseline-no-vendor.xml +++ b/tests/cputestdata/ppc64-baseline-no-vendor.xml @@ -1,7 +1,7 @@ <cpuTest> <cpu> <arch>ppc64</arch> - <model>POWER7_v2.3</model> + <model>power7</model> <topology sockets='2' cores='4' threads='1'/> </cpu> </cpuTest> diff --git a/tests/cputestdata/ppc64-exact.xml b/tests/cputestdata/ppc64-exact.xml index c84f16a..76900e8 100644 --- a/tests/cputestdata/ppc64-exact.xml +++ b/tests/cputestdata/ppc64-exact.xml @@ -1,3 +1,3 @@ <cpu match='exact'> - <model>POWER8_v1.0</model> + <model>power6</model> </cpu> diff --git a/tests/cputestdata/ppc64-guest-nofallback.xml b/tests/cputestdata/ppc64-guest-nofallback.xml index 42026b4..5539cfa 100644 --- a/tests/cputestdata/ppc64-guest-nofallback.xml +++ b/tests/cputestdata/ppc64-guest-nofallback.xml @@ -1,4 +1,4 @@ <cpu match='exact'> - <model fallback='forbid'>POWER7_v2.1</model> + <model fallback='forbid'>power7</model> <topology sockets='2' cores='4' threads='1'/> </cpu> diff --git a/tests/cputestdata/ppc64-guest.xml b/tests/cputestdata/ppc64-guest.xml index ac81ec0..967ad5a 100644 --- a/tests/cputestdata/ppc64-guest.xml +++ b/tests/cputestdata/ppc64-guest.xml @@ -1,4 +1,4 @@ <cpu match='exact'> - <model>POWER8_v1.0</model> + <model>power7</model> <topology sockets='2' cores='4' threads='1'/> </cpu> diff --git a/tests/cputestdata/ppc64-host+guest,ppc_models-result.xml b/tests/cputestdata/ppc64-host+guest,ppc_models-result.xml index 0cb0830..42e7bae 100644 --- a/tests/cputestdata/ppc64-host+guest,ppc_models-result.xml +++ b/tests/cputestdata/ppc64-host+guest,ppc_models-result.xml @@ -1,5 +1,5 @@ <cpu mode='custom' match='exact'> <arch>ppc64</arch> - <model fallback='allow'>POWER8_v1.0</model> + <model fallback='allow'>power7</model> <vendor>IBM</vendor> </cpu> diff --git a/tests/cputestdata/ppc64-host+guest-nofallback,ppc_models,POWER7_v2.1-result.xml b/tests/cputestdata/ppc64-host+guest-nofallback,ppc_models,POWER7_v2.1-result.xml deleted file mode 100644 index 7e58361..0000000 --- a/tests/cputestdata/ppc64-host+guest-nofallback,ppc_models,POWER7_v2.1-result.xml +++ /dev/null @@ -1,5 +0,0 @@ -<cpu mode='custom' match='exact'> - <arch>ppc64</arch> - <model fallback='forbid'>POWER7_v2.1</model> - <vendor>IBM</vendor> -</cpu> diff --git a/tests/cputestdata/ppc64-host+guest-nofallback,ppc_models,power7-result.xml b/tests/cputestdata/ppc64-host+guest-nofallback,ppc_models,power7-result.xml new file mode 100644 index 0000000..1f2711a --- /dev/null +++ b/tests/cputestdata/ppc64-host+guest-nofallback,ppc_models,power7-result.xml @@ -0,0 +1,5 @@ +<cpu mode='custom' match='exact'> + <arch>ppc64</arch> + <model fallback='forbid'>power7</model> + <vendor>IBM</vendor> +</cpu> diff --git a/tests/cputestdata/ppc64-host.xml b/tests/cputestdata/ppc64-host.xml index 39cb741..56d3d8f 100644 --- a/tests/cputestdata/ppc64-host.xml +++ b/tests/cputestdata/ppc64-host.xml @@ -1,6 +1,6 @@ <cpu> <arch>ppc64</arch> - <model>POWER7_v2.3</model> + <model>power7</model> <vendor>IBM</vendor> <topology sockets='1' cores='64' threads='1'/> </cpu> diff --git a/tests/cputestdata/ppc64-strict.xml b/tests/cputestdata/ppc64-strict.xml index e91c6e7..a507e32 100644 --- a/tests/cputestdata/ppc64-strict.xml +++ b/tests/cputestdata/ppc64-strict.xml @@ -1,3 +1,3 @@ <cpu match='exact'> - <model>POWER7_v2.3</model> + <model>power7</model> </cpu> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.args b/tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.args index 9927294..df38ab6 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.args @@ -1,5 +1,6 @@ LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test \ -QEMU_AUDIO_DRV=none /usr/bin/qemu-system-ppc64 -S -M pseries -cpu POWER7_v2.3 \ +QEMU_AUDIO_DRV=none /usr/bin/qemu-system-ppc64 -S -M pseries \ +-cpu host,compat=power6 \ -m 512 -smp 1 -nographic -nodefconfig -nodefaults \ -chardev socket,id=charmonitor,path=/tmp/test-monitor,server,nowait \ -mon chardev=charmonitor,id=monitor,mode=readline -no-acpi -boot c -usb \ diff --git a/tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.xml b/tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.xml index b54dae2..44cf506 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.xml @@ -7,7 +7,7 @@ <type arch='ppc64' machine='pseries'>hvm</type> </os> <cpu match='exact'> - <model>POWER7_v2.3</model> + <model fallback='compat'>power6</model> <vendor>IBM</vendor> </cpu> <clock offset='utc'/> -- 1.8.3.1 -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India
On Fri, Oct 10, 2014 at 03:54:28PM +0530, Prerna Saxena wrote:
From 67ca1c61d5e1c7de0c2d44e2ef47bc8bba39c159 Mon Sep 17 00:00:00 2001 From: "Pradipta Kr. Banerjee" <bpradip@in.ibm.com> Date: Tue, 7 Oct 2014 13:38:28 +0530
With reference to the previous update of cpu_map.xml, this patch fixes test cases for PowerPC CPUs. This also updates a test case for compat mode, introduced previously in the series.
Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Pradipta Kr. Banerjee <bpradip@in.ibm.com> Signed-off-by: Li Zhang <zhlcindy@linux.vnet.ibm.com> --- tests/cputest.c | 4 ++-- tests/cputestdata/ppc64-baseline-1-result.xml | 2 +- tests/cputestdata/ppc64-baseline-incompatible-vendors.xml | 4 ++-- tests/cputestdata/ppc64-baseline-no-vendor-result.xml | 2 +- tests/cputestdata/ppc64-baseline-no-vendor.xml | 2 +- tests/cputestdata/ppc64-exact.xml | 2 +- tests/cputestdata/ppc64-guest-nofallback.xml | 2 +- tests/cputestdata/ppc64-guest.xml | 2 +- tests/cputestdata/ppc64-host+guest,ppc_models-result.xml | 2 +- .../ppc64-host+guest-nofallback,ppc_models,POWER7_v2.1-result.xml | 5 ----- .../ppc64-host+guest-nofallback,ppc_models,power7-result.xml | 5 +++++ tests/cputestdata/ppc64-host.xml | 2 +- tests/cputestdata/ppc64-strict.xml | 2 +- tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.args | 3 ++- tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.xml | 2 +- 15 files changed, 21 insertions(+), 20 deletions(-) delete mode 100644 tests/cputestdata/ppc64-host+guest-nofallback,ppc_models,POWER7_v2.1-result.xml create mode 100644 tests/cputestdata/ppc64-host+guest-nofallback,ppc_models,power7-result.xml
diff --git a/tests/cputest.c b/tests/cputest.c index a507576..96b9dbf 100644 --- a/tests/cputest.c +++ b/tests/cputest.c @@ -496,7 +496,7 @@ cpuTestRun(const char *name, const struct data *data) static const char *model486[] = { "486" }; static const char *nomodel[] = { "nomodel" }; static const char *models[] = { "qemu64", "core2duo", "Nehalem" }; -static const char *ppc_models[] = { "POWER7", "POWER7_v2.1", "POWER8_v1.0"}; +static const char *ppc_models[] = { "power6", "power7", "power8"};
static int mymain(void) @@ -643,7 +643,7 @@ mymain(void) models, "Penryn", -1);
DO_TEST_GUESTDATA("ppc64", "host", "guest", ppc_models, NULL, 0); - DO_TEST_GUESTDATA("ppc64", "host", "guest-nofallback", ppc_models, "POWER7_v2.1", -1); + DO_TEST_GUESTDATA("ppc64", "host", "guest-nofallback", ppc_models, "power7", -1);
return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE; } diff --git a/tests/cputestdata/ppc64-baseline-1-result.xml b/tests/cputestdata/ppc64-baseline-1-result.xml index cbdd9bc..a330ef6 100644 --- a/tests/cputestdata/ppc64-baseline-1-result.xml +++ b/tests/cputestdata/ppc64-baseline-1-result.xml @@ -1,3 +1,3 @@ <cpu mode='custom' match='exact'> - <model fallback='allow'>POWER7+_v2.1</model> + <model fallback='allow'>power7</model> </cpu>
Having to update the tests in this way again just shows that you have broken compatibility with existing guest configs. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (2)
-
Daniel P. Berrange -
Prerna Saxena