5:01 a.m.
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
5:06 a.m.
New subject: [libvirt] [PATCH 1/4] PowerPC cpu: Add support for Power LE Architecture.
From effd8cf666074b2299b58da40d618810ec0fe3ff Mon Sep 17 00:00:00 2001
From: "Pradipta Kr. Banerjee" <bpradip(a)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(a)in.ibm.com>
Signed-off-by: Prerna Saxena <prerna(a)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
5:12 a.m.
New subject: [libvirt] [PATCH 2/4] PowerPC : Add support for launching VMs in 'compat' mode.
From 7228aacaa4b24907b1cbf33838ada8fb81890419 Mon Sep 17 00:00:00 2001
From: Prerna Saxena <prerna(a)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(a)linux.vnet.ibm.com>
Signed-off-by: Li Zhang <zhlcindy(a)linux.vnet.ibm.com>
Signed-off-by: Pradipta Kr. Banerjee <bpradip(a)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
5:16 a.m.
New subject: [libvirt] [PATCH 2/4] PowerPC : Add support for launching VMs in 'compat' mode.
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(a)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 :|
5:42 a.m.
New subject: [libvirt] [PATCH 2/4] PowerPC : Add support for launching VMs in 'compat' mode.
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(a)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
6:11 a.m.
New subject: [libvirt] [PATCH 2/4] PowerPC : Add support for launching VMs in 'compat' mode.
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(a)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 :|
6:18 a.m.
New subject: [libvirt] [PATCH 2/4] PowerPC : Add support for launching VMs in 'compat' mode.
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(a)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
5:21 a.m.
New subject: [libvirt] [PATCH 3/4] PowerPC cpu : Handle only high order 16 bits for PVR
From 1bcba78ed387a876208fec1ef60b81d65c8474e5 Mon Sep 17 00:00:00 2001
From: "Pradipta Kr. Banerjee" <bpradip(a)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(a)in.ibm.com>
Signed-off-by: Prerna Saxena <prerna(a)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
5:25 a.m.
New subject: [libvirt] [PATCH 3/4] PowerPC cpu : Handle only high order 16 bits for PVR
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(a)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(a)in.ibm.com>
Signed-off-by: Prerna Saxena <prerna(a)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 :|
5:57 a.m.
New subject: [libvirt] [PATCH 3/4] PowerPC cpu : Handle only high order 16 bits for PVR
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(a)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(a)in.ibm.com>
> Signed-off-by: Prerna Saxena <prerna(a)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
6:08 a.m.
New subject: [libvirt] [PATCH 3/4] PowerPC cpu : Handle only high order 16 bits for PVR
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(a)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(a)in.ibm.com>
>> Signed-off-by: Prerna Saxena <prerna(a)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 :|
6:26 a.m.
New subject: [libvirt] [PATCH 3/4] PowerPC cpu : Handle only high order 16 bits for PVR
On Friday 10 October 2014 04:38 PM, Daniel P. Berrange wrote:
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(a)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(a)in.ibm.com>
>>> Signed-off-by: Prerna Saxena <prerna(a)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
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
5:24 a.m.
New subject: [libvirt] [PATCH 4/4] Update cputest test cases for PowerPC CPU models
From 67ca1c61d5e1c7de0c2d44e2ef47bc8bba39c159 Mon Sep 17 00:00:00 2001
From: "Pradipta Kr. Banerjee" <bpradip(a)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(a)linux.vnet.ibm.com>
Signed-off-by: Pradipta Kr. Banerjee <bpradip(a)in.ibm.com>
Signed-off-by: Li Zhang <zhlcindy(a)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
5:27 a.m.
New subject: [libvirt] [PATCH 4/4] Update cputest test cases for PowerPC CPU models
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(a)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(a)linux.vnet.ibm.com>
Signed-off-by: Pradipta Kr. Banerjee <bpradip(a)in.ibm.com>
Signed-off-by: Li Zhang <zhlcindy(a)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 :|
3696
days inactive
3696
days old
13 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Prerna Saxena