Re: [Qemu-devel] [RFC PATCH] spapr: add initial ibm, client-architecture-support rtas call support
On Wed, Sep 04, 2013 at 04:32:20PM -0500, Anthony Liguori wrote: On Wed, Sep 4, 2013 at 8:37 AM, Alexander Graf ag...@suse.de wrote: So IMHO this whole thing should be orthogonal to -cpu. Well, since we cannot change CPU class on the fly, yes, it should be a compatibility flags/properties/methods/whatever of the default CPU for the specific family. Since it's machine global, it could just as well be a machine option, no? Or can you have multiple CPUs with different compat modes in a single system? AFAIK, this has nothing to do with CPUs. I'm not sure what you mean by that; it has to do with CPUs since it means changing the CPUs' behaviour, at least for user-mode programs. Why? Just because you're on POWER7 as default doesn't mean you can't bump to a newer compat later on, no? Bump when exactly? And it won't be a new compat, it will be a native CPU. I If you configure your guest to boot in POWER7-compat mode on your POWER8 box and it then tells you through ibm,client-architecture-support that it can do POWER8, we can just remove all the compat bits and be happy, no? Answering Alex here -- if we want to preserve the option of migrating to a POWER7 host in future, we would run the guest in POWER7 compat mode even if the current host is a POWER8 and the guest knows about POWER8. POWER8 is compatible with POWER7, right? There's no magic bits that need to be disabled AFAIK. POWER8 is a superset of POWER7, yes, but what we want to do when running an old OS and applications that don't know about POWER8 is to disable the new POWER8 features in usermode (e.g., transactional memory, various other new instructions, etc.). The reason is to make it more likely that applications won't misbehave even if they do silly things like trying instructions that aren't defined on POWER7 (or at least, they will behave the same as they would on a real POWER7). To this end, the processor has a Processor Compatibility Register (PCR) which has bits which disables the new instructions and SPRs when the processor is in user mode - actually 2 bits, one which disables the features that were new for POWER8 compared to POWER7, and one which disables the features that were new for POWER7 compared to POWER6. The effective version if exposed through device tree. The reason a reboot is needed is because the device tree needs to be updated (which can't be done without a reboot). The problem to solve is delaying device tree generation in order to avoid the reboots, no? No, we can't delay generating the device tree to that point. SLOF needs the device tree, and the kernel does look at the device tree before calling the ibm,client-architecture-support method. (Maybe it's time to start thinking of non-PAPR interfaces that Linux KVM guests can use to avoid a lot of this silliness...) That won't help us boot (e.g.) RHEL6 or SLES11 on a POWER8, which is what this is ultimately about. In any case, there are changes we might need to make that will definitely need a reboot - changing the size of the hashed page table, for instance. Paul.
Re: [Qemu-devel] [RFC PATCH] spapr: add initial ibm, client-architecture-support rtas call support
On 05.09.2013, at 12:16, Paul Mackerras wrote: On Wed, Sep 04, 2013 at 04:32:20PM -0500, Anthony Liguori wrote: On Wed, Sep 4, 2013 at 8:37 AM, Alexander Graf ag...@suse.de wrote: So IMHO this whole thing should be orthogonal to -cpu. Well, since we cannot change CPU class on the fly, yes, it should be a compatibility flags/properties/methods/whatever of the default CPU for the specific family. Since it's machine global, it could just as well be a machine option, no? Or can you have multiple CPUs with different compat modes in a single system? AFAIK, this has nothing to do with CPUs. I'm not sure what you mean by that; it has to do with CPUs since it means changing the CPUs' behaviour, at least for user-mode programs. Why? Just because you're on POWER7 as default doesn't mean you can't bump to a newer compat later on, no? Bump when exactly? And it won't be a new compat, it will be a native CPU. I If you configure your guest to boot in POWER7-compat mode on your POWER8 box and it then tells you through ibm,client-architecture-support that it can do POWER8, we can just remove all the compat bits and be happy, no? Answering Alex here -- if we want to preserve the option of migrating to a POWER7 host in future, we would run the guest in POWER7 compat mode even if the current host is a POWER8 and the guest knows about POWER8. Yes, so we boot the guest with compat mode set to POWER7, then the guest calls ibm,client-architecutre-support including POWER8 and then we can reconfigure the guest to be POWER8, right? Alex
Re: [Qemu-devel] [RFC PATCH] spapr: add initial ibm, client-architecture-support rtas call support
On Thu, Sep 05, 2013 at 12:19:09PM +0200, Alexander Graf wrote: On 05.09.2013, at 12:16, Paul Mackerras wrote: On Wed, Sep 04, 2013 at 04:32:20PM -0500, Anthony Liguori wrote: On Wed, Sep 4, 2013 at 8:37 AM, Alexander Graf ag...@suse.de wrote: So IMHO this whole thing should be orthogonal to -cpu. Well, since we cannot change CPU class on the fly, yes, it should be a compatibility flags/properties/methods/whatever of the default CPU for the specific family. Since it's machine global, it could just as well be a machine option, no? Or can you have multiple CPUs with different compat modes in a single system? AFAIK, this has nothing to do with CPUs. I'm not sure what you mean by that; it has to do with CPUs since it means changing the CPUs' behaviour, at least for user-mode programs. Why? Just because you're on POWER7 as default doesn't mean you can't bump to a newer compat later on, no? Bump when exactly? And it won't be a new compat, it will be a native CPU. I If you configure your guest to boot in POWER7-compat mode on your POWER8 box and it then tells you through ibm,client-architecture-support that it can do POWER8, we can just remove all the compat bits and be happy, no? Answering Alex here -- if we want to preserve the option of migrating to a POWER7 host in future, we would run the guest in POWER7 compat mode even if the current host is a POWER8 and the guest knows about POWER8. Yes, so we boot the guest with compat mode set to POWER7, then the guest calls ibm,client-architecutre-support including POWER8 and then we can reconfigure the guest to be POWER8, right? Not if we want to be able to migrate to a real POWER7 later. If we tell the guest it's a POWER8, it will start using POWER8 features, and then break when we migrate it to a POWER7 where those features don't exist. If we run the POWER8 in POWER7 compatibility mode (and more importantly, the device tree says it's a 2.06 architecture processor), it should only use POWER7 features and then work just fine when migrated to a real POWER7. Paul.
Re: [Qemu-devel] [RFC PATCH] spapr: add initial ibm, client-architecture-support rtas call support
On 05.09.2013, at 13:55, Paul Mackerras wrote: On Thu, Sep 05, 2013 at 12:19:09PM +0200, Alexander Graf wrote: On 05.09.2013, at 12:16, Paul Mackerras wrote: On Wed, Sep 04, 2013 at 04:32:20PM -0500, Anthony Liguori wrote: On Wed, Sep 4, 2013 at 8:37 AM, Alexander Graf ag...@suse.de wrote: So IMHO this whole thing should be orthogonal to -cpu. Well, since we cannot change CPU class on the fly, yes, it should be a compatibility flags/properties/methods/whatever of the default CPU for the specific family. Since it's machine global, it could just as well be a machine option, no? Or can you have multiple CPUs with different compat modes in a single system? AFAIK, this has nothing to do with CPUs. I'm not sure what you mean by that; it has to do with CPUs since it means changing the CPUs' behaviour, at least for user-mode programs. Why? Just because you're on POWER7 as default doesn't mean you can't bump to a newer compat later on, no? Bump when exactly? And it won't be a new compat, it will be a native CPU. I If you configure your guest to boot in POWER7-compat mode on your POWER8 box and it then tells you through ibm,client-architecture-support that it can do POWER8, we can just remove all the compat bits and be happy, no? Answering Alex here -- if we want to preserve the option of migrating to a POWER7 host in future, we would run the guest in POWER7 compat mode even if the current host is a POWER8 and the guest knows about POWER8. Yes, so we boot the guest with compat mode set to POWER7, then the guest calls ibm,client-architecutre-support including POWER8 and then we can reconfigure the guest to be POWER8, right? Not if we want to be able to migrate to a real POWER7 later. If we tell the guest it's a POWER8, it will start using POWER8 features, and then break when we migrate it to a POWER7 where those features don't exist. If we run the POWER8 in POWER7 compatibility mode (and more importantly, the device tree says it's a 2.06 architecture processor), it should only use POWER7 features and then work just fine when migrated to a real POWER7. Ah, ok. So we want to be able to specify 2 things: - current compat level - max compat level That way we can boot a POWER8 virtual machine in POWER7 compat mode straight on boot, but allow that machine to later reconfigure itself if it isn't configured to POWER7 as max compat level. The current level is mostly a convenience thing to not have to reboot SLOF every time you boot up a guest. The max level is what gives you compatibility throughout a cluster of machines. Or do I miss anything here? Alex
Re: [Qemu-devel] [RFC PATCH] spapr: add initial ibm, client-architecture-support rtas call support
On 04.09.2013, at 12:19, Alexey Kardashevskiy wrote:
This is an RFC patch.
The modern Linux kernel supports every known POWERPC CPU so when
it boots, it can always find a matching cpu_spec from the cpu_specs array.
However if the kernel is quite old, it may be missing the definition of
the actual CPU. To provide ability for old kernels to work on modern
hardware, a Logical Processor Version concept was introduced in PowerISA.
From the hardware prospective, it is supported by PCR (Processor
Compatibility Register) which is defined in PowerISA. The register
enables compatibility mode which can be set to PowerISA 2.05 or 2.06.
PAPR+ specification defines a Logical Processor Version per every
version of PowerISA specification. PAPR+ also defines
a ibm,client-architecture-support rtas call which purpose is to provide
a negotiation mechanism for the guest and the hypervisor to work out
the best Logical Processor Version to continue with.
At the moment, the Linux kernel calls the ibm,client-architecture-support
method and only then reads the device. The current RTAS's handler checks
the capabilities from the array supplied by the guest kernel, analyses
if QEMU can or cannot provide with the requested features.
If QEMU supports everything the guest has requested, it returns from rtas
call and the guest continues booting.
If some parameter changes, QEMU fixes the device tree and reboots
the guest with a new tree.
In this version, the ibm,client-architecture-support handler checks
if the current CPU is in the list from the guest and if it is not, QEMU
adds a cpu-version property to a cpu node with the best of logical PVRs
supported by the guest.
Technically QEMU reboots and as a part of reboot, it fixes the tree and
this is when the cpu-version property is actually added.
Although it seems possible to add a custom interface between SLOF and QEMU
and implement device tree update on the fly to avoid a guest reboot,
there still may be cases when device tree change would not be enough.
As an example, the guest may ask for a bigger RMA area than QEMU allocates
by default.
The patch depends on [PATCH v5] powerpc: add PVR mask support.
Cc: Nikunj A Dadhania nik...@linux.vnet.ibm.com
Cc: Andreas Färber afaer...@suse.de
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
hw/ppc/spapr.c | 10 ++
hw/ppc/spapr_hcall.c| 76 +
include/hw/ppc/spapr.h | 7 -
target-ppc/cpu-models.h | 13
target-ppc/cpu-qom.h| 1 +
target-ppc/translate_init.c | 3 ++
6 files changed, 109 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 13574bf..5adf53c 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -238,6 +238,16 @@ static int spapr_fixup_cpu_dt(void *fdt,
sPAPREnvironment *spapr)
if (ret 0) {
return ret;
}
+
+if (spapr-pvr_new) {
+ret = fdt_setprop(fdt, offset, cpu-version,
+ spapr-pvr_new, sizeof(spapr-pvr_new));
+if (ret 0) {
+return ret;
+}
+/* Reset as the guest after reboot may give other PVR set */
+spapr-pvr_new = 0;
+}
}
return ret;
}
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 9f6e7b8..509de89 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -3,6 +3,7 @@
#include helper_regs.h
#include hw/ppc/spapr.h
#include mmu-hash64.h
+#include cpu-models.h
static target_ulong h_random(PowerPCCPU *cpu, sPAPREnvironment *spapr,
target_ulong opcode, target_ulong *args)
@@ -792,6 +793,78 @@ out:
return ret;
}
+static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
+ sPAPREnvironment *spapr,
+ target_ulong opcode,
+ target_ulong *args)
+{
+target_ulong list = args[0];
+int i, number_of_option_vectors;
+PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
+bool cpu_match = false;
+unsigned compat_cpu_level = 0, pvr_new;
+
+/* Parse PVR list */
+for ( ; ; ) {
+uint32_t pvr, pvr_mask;
+
+pvr_mask = ldl_phys(list);
+list += 4;
+pvr = ldl_phys(list);
+list += 4;
+
+if ((cpu-env.spr[SPR_PVR] pvr_mask) == (pvr pvr_mask)) {
+cpu_match = true;
+pvr_new = cpu-env.spr[SPR_PVR];
+}
+
+/* Is it a logical PVR? */
+if ((pvr CPU_POWERPC_LOGICAL_MASK) == CPU_POWERPC_LOGICAL_MASK) {
+switch (pvr) {
+case CPU_POWERPC_LOGICAL_2_05:
+if ((pcc-pcr POWERPC_ISA_COMPAT_2_05)
+(compat_cpu_level 2050)) {
+compat_cpu_level = 2050;
+
Re: [Qemu-devel] [RFC PATCH] spapr: add initial ibm, client-architecture-support rtas call support
On 09/04/2013 08:42 PM, Alexander Graf wrote:
On 04.09.2013, at 12:19, Alexey Kardashevskiy wrote:
This is an RFC patch.
The modern Linux kernel supports every known POWERPC CPU so when
it boots, it can always find a matching cpu_spec from the cpu_specs array.
However if the kernel is quite old, it may be missing the definition of
the actual CPU. To provide ability for old kernels to work on modern
hardware, a Logical Processor Version concept was introduced in PowerISA.
From the hardware prospective, it is supported by PCR (Processor
Compatibility Register) which is defined in PowerISA. The register
enables compatibility mode which can be set to PowerISA 2.05 or 2.06.
PAPR+ specification defines a Logical Processor Version per every
version of PowerISA specification. PAPR+ also defines
a ibm,client-architecture-support rtas call which purpose is to provide
a negotiation mechanism for the guest and the hypervisor to work out
the best Logical Processor Version to continue with.
At the moment, the Linux kernel calls the ibm,client-architecture-support
method and only then reads the device. The current RTAS's handler checks
the capabilities from the array supplied by the guest kernel, analyses
if QEMU can or cannot provide with the requested features.
If QEMU supports everything the guest has requested, it returns from rtas
call and the guest continues booting.
If some parameter changes, QEMU fixes the device tree and reboots
the guest with a new tree.
In this version, the ibm,client-architecture-support handler checks
if the current CPU is in the list from the guest and if it is not, QEMU
adds a cpu-version property to a cpu node with the best of logical PVRs
supported by the guest.
Technically QEMU reboots and as a part of reboot, it fixes the tree and
this is when the cpu-version property is actually added.
Although it seems possible to add a custom interface between SLOF and QEMU
and implement device tree update on the fly to avoid a guest reboot,
there still may be cases when device tree change would not be enough.
As an example, the guest may ask for a bigger RMA area than QEMU allocates
by default.
The patch depends on [PATCH v5] powerpc: add PVR mask support.
Cc: Nikunj A Dadhania nik...@linux.vnet.ibm.com
Cc: Andreas Färber afaer...@suse.de
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
hw/ppc/spapr.c | 10 ++
hw/ppc/spapr_hcall.c| 76
+
include/hw/ppc/spapr.h | 7 -
target-ppc/cpu-models.h | 13
target-ppc/cpu-qom.h| 1 +
target-ppc/translate_init.c | 3 ++
6 files changed, 109 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 13574bf..5adf53c 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -238,6 +238,16 @@ static int spapr_fixup_cpu_dt(void *fdt,
sPAPREnvironment *spapr)
if (ret 0) {
return ret;
}
+
+if (spapr-pvr_new) {
+ret = fdt_setprop(fdt, offset, cpu-version,
+ spapr-pvr_new, sizeof(spapr-pvr_new));
+if (ret 0) {
+return ret;
+}
+/* Reset as the guest after reboot may give other PVR set */
+spapr-pvr_new = 0;
+}
}
return ret;
}
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 9f6e7b8..509de89 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -3,6 +3,7 @@
#include helper_regs.h
#include hw/ppc/spapr.h
#include mmu-hash64.h
+#include cpu-models.h
static target_ulong h_random(PowerPCCPU *cpu, sPAPREnvironment *spapr,
target_ulong opcode, target_ulong *args)
@@ -792,6 +793,78 @@ out:
return ret;
}
+static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
+ sPAPREnvironment *spapr,
+ target_ulong opcode,
+ target_ulong *args)
+{
+target_ulong list = args[0];
+int i, number_of_option_vectors;
+PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
+bool cpu_match = false;
+unsigned compat_cpu_level = 0, pvr_new;
+
+/* Parse PVR list */
+for ( ; ; ) {
+uint32_t pvr, pvr_mask;
+
+pvr_mask = ldl_phys(list);
+list += 4;
+pvr = ldl_phys(list);
+list += 4;
+
+if ((cpu-env.spr[SPR_PVR] pvr_mask) == (pvr pvr_mask)) {
+cpu_match = true;
+pvr_new = cpu-env.spr[SPR_PVR];
+}
+
+/* Is it a logical PVR? */
+if ((pvr CPU_POWERPC_LOGICAL_MASK) == CPU_POWERPC_LOGICAL_MASK) {
+switch (pvr) {
+case CPU_POWERPC_LOGICAL_2_05:
+if ((pcc-pcr POWERPC_ISA_COMPAT_2_05)
+(compat_cpu_level 2050)) {
+
Re: [Qemu-devel] [RFC PATCH] spapr: add initial ibm, client-architecture-support rtas call support
On Wed, 2013-09-04 at 21:40 +1000, Alexey Kardashevskiy wrote: One of the examples (came from Paul) is: the host runs on POWER8, the guest boots a kernel which is capable of POWER7 only + POWER7-compat. We do this reboot tweak and boot in POWER7-compat mode. Then the guest does yum update and gets POWER8 kernel installed so when it reboots, it will boot in normal POWER8 mode. Everybody is happy. Having POWER7-compat mode set from the very beginning will break this behaviour. But it will allow migrating that partition to a P7 machine. It's important to be able to specify the compat mode for that reason, to create guests that can be migrated to older machines. Cheers, Ben.
Re: [Qemu-devel] [RFC PATCH] spapr: add initial ibm, client-architecture-support rtas call support
On 04.09.2013, at 13:40, Alexey Kardashevskiy wrote:
On 09/04/2013 08:42 PM, Alexander Graf wrote:
On 04.09.2013, at 12:19, Alexey Kardashevskiy wrote:
This is an RFC patch.
The modern Linux kernel supports every known POWERPC CPU so when
it boots, it can always find a matching cpu_spec from the cpu_specs array.
However if the kernel is quite old, it may be missing the definition of
the actual CPU. To provide ability for old kernels to work on modern
hardware, a Logical Processor Version concept was introduced in PowerISA.
From the hardware prospective, it is supported by PCR (Processor
Compatibility Register) which is defined in PowerISA. The register
enables compatibility mode which can be set to PowerISA 2.05 or 2.06.
PAPR+ specification defines a Logical Processor Version per every
version of PowerISA specification. PAPR+ also defines
a ibm,client-architecture-support rtas call which purpose is to provide
a negotiation mechanism for the guest and the hypervisor to work out
the best Logical Processor Version to continue with.
At the moment, the Linux kernel calls the ibm,client-architecture-support
method and only then reads the device. The current RTAS's handler checks
the capabilities from the array supplied by the guest kernel, analyses
if QEMU can or cannot provide with the requested features.
If QEMU supports everything the guest has requested, it returns from rtas
call and the guest continues booting.
If some parameter changes, QEMU fixes the device tree and reboots
the guest with a new tree.
In this version, the ibm,client-architecture-support handler checks
if the current CPU is in the list from the guest and if it is not, QEMU
adds a cpu-version property to a cpu node with the best of logical PVRs
supported by the guest.
Technically QEMU reboots and as a part of reboot, it fixes the tree and
this is when the cpu-version property is actually added.
Although it seems possible to add a custom interface between SLOF and QEMU
and implement device tree update on the fly to avoid a guest reboot,
there still may be cases when device tree change would not be enough.
As an example, the guest may ask for a bigger RMA area than QEMU allocates
by default.
The patch depends on [PATCH v5] powerpc: add PVR mask support.
Cc: Nikunj A Dadhania nik...@linux.vnet.ibm.com
Cc: Andreas Färber afaer...@suse.de
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
hw/ppc/spapr.c | 10 ++
hw/ppc/spapr_hcall.c| 76
+
include/hw/ppc/spapr.h | 7 -
target-ppc/cpu-models.h | 13
target-ppc/cpu-qom.h| 1 +
target-ppc/translate_init.c | 3 ++
6 files changed, 109 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 13574bf..5adf53c 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -238,6 +238,16 @@ static int spapr_fixup_cpu_dt(void *fdt,
sPAPREnvironment *spapr)
if (ret 0) {
return ret;
}
+
+if (spapr-pvr_new) {
+ret = fdt_setprop(fdt, offset, cpu-version,
+ spapr-pvr_new, sizeof(spapr-pvr_new));
+if (ret 0) {
+return ret;
+}
+/* Reset as the guest after reboot may give other PVR set */
+spapr-pvr_new = 0;
+}
}
return ret;
}
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 9f6e7b8..509de89 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -3,6 +3,7 @@
#include helper_regs.h
#include hw/ppc/spapr.h
#include mmu-hash64.h
+#include cpu-models.h
static target_ulong h_random(PowerPCCPU *cpu, sPAPREnvironment *spapr,
target_ulong opcode, target_ulong *args)
@@ -792,6 +793,78 @@ out:
return ret;
}
+static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
+ sPAPREnvironment *spapr,
+ target_ulong opcode,
+ target_ulong *args)
+{
+target_ulong list = args[0];
+int i, number_of_option_vectors;
+PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
+bool cpu_match = false;
+unsigned compat_cpu_level = 0, pvr_new;
+
+/* Parse PVR list */
+for ( ; ; ) {
+uint32_t pvr, pvr_mask;
+
+pvr_mask = ldl_phys(list);
+list += 4;
+pvr = ldl_phys(list);
+list += 4;
+
+if ((cpu-env.spr[SPR_PVR] pvr_mask) == (pvr pvr_mask)) {
+cpu_match = true;
+pvr_new = cpu-env.spr[SPR_PVR];
+}
+
+/* Is it a logical PVR? */
+if ((pvr CPU_POWERPC_LOGICAL_MASK) == CPU_POWERPC_LOGICAL_MASK) {
+switch (pvr) {
+case CPU_POWERPC_LOGICAL_2_05:
+if ((pcc-pcr POWERPC_ISA_COMPAT_2_05)
Re: [Qemu-devel] [RFC PATCH] spapr: add initial ibm, client-architecture-support rtas call support
On 09/04/2013 09:54 PM, Benjamin Herrenschmidt wrote: On Wed, 2013-09-04 at 21:40 +1000, Alexey Kardashevskiy wrote: One of the examples (came from Paul) is: the host runs on POWER8, the guest boots a kernel which is capable of POWER7 only + POWER7-compat. We do this reboot tweak and boot in POWER7-compat mode. Then the guest does yum update and gets POWER8 kernel installed so when it reboots, it will boot in normal POWER8 mode. Everybody is happy. Having POWER7-compat mode set from the very beginning will break this behaviour. But it will allow migrating that partition to a P7 machine. It's important to be able to specify the compat mode for that reason, to create guests that can be migrated to older machines. I am not saying we do not need this feature, I am saying we do not always want it. -- Alexey
Re: [Qemu-devel] [RFC PATCH] spapr: add initial ibm, client-architecture-support rtas call support
On 04.09.2013, at 15:08, Alexey Kardashevskiy wrote:
On 09/04/2013 10:13 PM, Alexander Graf wrote:
On 04.09.2013, at 13:40, Alexey Kardashevskiy wrote:
On 09/04/2013 08:42 PM, Alexander Graf wrote:
On 04.09.2013, at 12:19, Alexey Kardashevskiy wrote:
This is an RFC patch.
The modern Linux kernel supports every known POWERPC CPU so when
it boots, it can always find a matching cpu_spec from the cpu_specs array.
However if the kernel is quite old, it may be missing the definition of
the actual CPU. To provide ability for old kernels to work on modern
hardware, a Logical Processor Version concept was introduced in PowerISA.
From the hardware prospective, it is supported by PCR (Processor
Compatibility Register) which is defined in PowerISA. The register
enables compatibility mode which can be set to PowerISA 2.05 or 2.06.
PAPR+ specification defines a Logical Processor Version per every
version of PowerISA specification. PAPR+ also defines
a ibm,client-architecture-support rtas call which purpose is to provide
a negotiation mechanism for the guest and the hypervisor to work out
the best Logical Processor Version to continue with.
At the moment, the Linux kernel calls the ibm,client-architecture-support
method and only then reads the device. The current RTAS's handler checks
the capabilities from the array supplied by the guest kernel, analyses
if QEMU can or cannot provide with the requested features.
If QEMU supports everything the guest has requested, it returns from rtas
call and the guest continues booting.
If some parameter changes, QEMU fixes the device tree and reboots
the guest with a new tree.
In this version, the ibm,client-architecture-support handler checks
if the current CPU is in the list from the guest and if it is not, QEMU
adds a cpu-version property to a cpu node with the best of logical PVRs
supported by the guest.
Technically QEMU reboots and as a part of reboot, it fixes the tree and
this is when the cpu-version property is actually added.
Although it seems possible to add a custom interface between SLOF and QEMU
and implement device tree update on the fly to avoid a guest reboot,
there still may be cases when device tree change would not be enough.
As an example, the guest may ask for a bigger RMA area than QEMU allocates
by default.
The patch depends on [PATCH v5] powerpc: add PVR mask support.
Cc: Nikunj A Dadhania nik...@linux.vnet.ibm.com
Cc: Andreas Färber afaer...@suse.de
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
hw/ppc/spapr.c | 10 ++
hw/ppc/spapr_hcall.c| 76
+
include/hw/ppc/spapr.h | 7 -
target-ppc/cpu-models.h | 13
target-ppc/cpu-qom.h| 1 +
target-ppc/translate_init.c | 3 ++
6 files changed, 109 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 13574bf..5adf53c 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -238,6 +238,16 @@ static int spapr_fixup_cpu_dt(void *fdt,
sPAPREnvironment *spapr)
if (ret 0) {
return ret;
}
+
+if (spapr-pvr_new) {
+ret = fdt_setprop(fdt, offset, cpu-version,
+ spapr-pvr_new, sizeof(spapr-pvr_new));
+if (ret 0) {
+return ret;
+}
+/* Reset as the guest after reboot may give other PVR set */
+spapr-pvr_new = 0;
+}
}
return ret;
}
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 9f6e7b8..509de89 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -3,6 +3,7 @@
#include helper_regs.h
#include hw/ppc/spapr.h
#include mmu-hash64.h
+#include cpu-models.h
static target_ulong h_random(PowerPCCPU *cpu, sPAPREnvironment *spapr,
target_ulong opcode, target_ulong *args)
@@ -792,6 +793,78 @@ out:
return ret;
}
+static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
+ sPAPREnvironment
*spapr,
+ target_ulong opcode,
+ target_ulong *args)
+{
+target_ulong list = args[0];
+int i, number_of_option_vectors;
+PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
+bool cpu_match = false;
+unsigned compat_cpu_level = 0, pvr_new;
+
+/* Parse PVR list */
+for ( ; ; ) {
+uint32_t pvr, pvr_mask;
+
+pvr_mask = ldl_phys(list);
+list += 4;
+pvr = ldl_phys(list);
+list += 4;
+
+if ((cpu-env.spr[SPR_PVR] pvr_mask) == (pvr pvr_mask)) {
+cpu_match = true;
+pvr_new = cpu-env.spr[SPR_PVR];
+}
+
+/* Is it a logical PVR? */
+if ((pvr CPU_POWERPC_LOGICAL_MASK) ==
CPU_POWERPC_LOGICAL_MASK) {
+switch (pvr) {
+
Re: [Qemu-devel] [RFC PATCH] spapr: add initial ibm, client-architecture-support rtas call support
On 09/04/2013 10:13 PM, Alexander Graf wrote:
On 04.09.2013, at 13:40, Alexey Kardashevskiy wrote:
On 09/04/2013 08:42 PM, Alexander Graf wrote:
On 04.09.2013, at 12:19, Alexey Kardashevskiy wrote:
This is an RFC patch.
The modern Linux kernel supports every known POWERPC CPU so when
it boots, it can always find a matching cpu_spec from the cpu_specs array.
However if the kernel is quite old, it may be missing the definition of
the actual CPU. To provide ability for old kernels to work on modern
hardware, a Logical Processor Version concept was introduced in PowerISA.
From the hardware prospective, it is supported by PCR (Processor
Compatibility Register) which is defined in PowerISA. The register
enables compatibility mode which can be set to PowerISA 2.05 or 2.06.
PAPR+ specification defines a Logical Processor Version per every
version of PowerISA specification. PAPR+ also defines
a ibm,client-architecture-support rtas call which purpose is to provide
a negotiation mechanism for the guest and the hypervisor to work out
the best Logical Processor Version to continue with.
At the moment, the Linux kernel calls the ibm,client-architecture-support
method and only then reads the device. The current RTAS's handler checks
the capabilities from the array supplied by the guest kernel, analyses
if QEMU can or cannot provide with the requested features.
If QEMU supports everything the guest has requested, it returns from rtas
call and the guest continues booting.
If some parameter changes, QEMU fixes the device tree and reboots
the guest with a new tree.
In this version, the ibm,client-architecture-support handler checks
if the current CPU is in the list from the guest and if it is not, QEMU
adds a cpu-version property to a cpu node with the best of logical PVRs
supported by the guest.
Technically QEMU reboots and as a part of reboot, it fixes the tree and
this is when the cpu-version property is actually added.
Although it seems possible to add a custom interface between SLOF and QEMU
and implement device tree update on the fly to avoid a guest reboot,
there still may be cases when device tree change would not be enough.
As an example, the guest may ask for a bigger RMA area than QEMU allocates
by default.
The patch depends on [PATCH v5] powerpc: add PVR mask support.
Cc: Nikunj A Dadhania nik...@linux.vnet.ibm.com
Cc: Andreas Färber afaer...@suse.de
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
hw/ppc/spapr.c | 10 ++
hw/ppc/spapr_hcall.c| 76
+
include/hw/ppc/spapr.h | 7 -
target-ppc/cpu-models.h | 13
target-ppc/cpu-qom.h| 1 +
target-ppc/translate_init.c | 3 ++
6 files changed, 109 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 13574bf..5adf53c 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -238,6 +238,16 @@ static int spapr_fixup_cpu_dt(void *fdt,
sPAPREnvironment *spapr)
if (ret 0) {
return ret;
}
+
+if (spapr-pvr_new) {
+ret = fdt_setprop(fdt, offset, cpu-version,
+ spapr-pvr_new, sizeof(spapr-pvr_new));
+if (ret 0) {
+return ret;
+}
+/* Reset as the guest after reboot may give other PVR set */
+spapr-pvr_new = 0;
+}
}
return ret;
}
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 9f6e7b8..509de89 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -3,6 +3,7 @@
#include helper_regs.h
#include hw/ppc/spapr.h
#include mmu-hash64.h
+#include cpu-models.h
static target_ulong h_random(PowerPCCPU *cpu, sPAPREnvironment *spapr,
target_ulong opcode, target_ulong *args)
@@ -792,6 +793,78 @@ out:
return ret;
}
+static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
+ sPAPREnvironment *spapr,
+ target_ulong opcode,
+ target_ulong *args)
+{
+target_ulong list = args[0];
+int i, number_of_option_vectors;
+PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
+bool cpu_match = false;
+unsigned compat_cpu_level = 0, pvr_new;
+
+/* Parse PVR list */
+for ( ; ; ) {
+uint32_t pvr, pvr_mask;
+
+pvr_mask = ldl_phys(list);
+list += 4;
+pvr = ldl_phys(list);
+list += 4;
+
+if ((cpu-env.spr[SPR_PVR] pvr_mask) == (pvr pvr_mask)) {
+cpu_match = true;
+pvr_new = cpu-env.spr[SPR_PVR];
+}
+
+/* Is it a logical PVR? */
+if ((pvr CPU_POWERPC_LOGICAL_MASK) == CPU_POWERPC_LOGICAL_MASK)
{
+switch (pvr) {
+case CPU_POWERPC_LOGICAL_2_05:
+if
Re: [Qemu-devel] [RFC PATCH] spapr: add initial ibm, client-architecture-support rtas call support
On Wed, Sep 4, 2013 at 8:37 AM, Alexander Graf ag...@suse.de wrote: So IMHO this whole thing should be orthogonal to -cpu. Well, since we cannot change CPU class on the fly, yes, it should be a compatibility flags/properties/methods/whatever of the default CPU for the specific family. Since it's machine global, it could just as well be a machine option, no? Or can you have multiple CPUs with different compat modes in a single system? AFAIK, this has nothing to do with CPUs. Why? Just because you're on POWER7 as default doesn't mean you can't bump to a newer compat later on, no? Bump when exactly? And it won't be a new compat, it will be a native CPU. I If you configure your guest to boot in POWER7-compat mode on your POWER8 box and it then tells you through ibm,client-architecture-support that it can do POWER8, we can just remove all the compat bits and be happy, no? POWER8 is compatible with POWER7, right? There's no magic bits that need to be disabled AFAIK. The effective version if exposed through device tree. The reason a reboot is needed is because the device tree needs to be updated (which can't be done without a reboot). The problem to solve is delaying device tree generation in order to avoid the reboots, no? (Maybe it's time to start thinking of non-PAPR interfaces that Linux KVM guests can use to avoid a lot of this silliness...) thought you are totally against reboots and you want libvirt (for example) to detect that this was ibm,client-architecture-support and reboot the guest with new CPU type (or machine option). I'm not sure which way the best one forward is, but at first we need to get something working that feels natural for people coming from x86 as well as pHyp. So I think we should enable both use cases. We should do the on-the-fly transitioning in QEMU with the chance of libvirt intercepting it. I don't think the intercepting part is a hard requirement today, but we should keep it in mind to know the full picture. That way a client-architecture-support rtas call can either reboot the system and automatically do the right thing and/or it can tell libvirt via QMP that we changed the client-architecture-support which means libvirt now has the chance to reconfigure the default setting next time it spawns a VM. Which gets us to the third bit. You need to be able to tell QEMU what the default client-architecture-support level is when you boot a VM to make sure that a POWER7 guest on a POWER8 system doesn't always reboot to reconfigure itself first thing when it boots up. As Ben mentioned, migration is obviously a strong point for this one too. So what do we need? - machine flag to indicate compat level - machine reset evaluates compat level, adjusts VM accordingly - rtas call merely modifies machine flag and triggers a reset - optional: QMP notifier when the rtas call changed the machine flag Regards, Anthony Liguori Alex
