From: Alexander Graf <agraf@suse.de>
To: Alexey Kardashevskiy <aik@ozlabs.ru>, qemu-devel@nongnu.org
Cc: qemu-ppc@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 8/9] spapr: Implement processor compatibility in ibm, client-architecture-support
Date: Fri, 16 May 2014 22:46:26 +0200 [thread overview]
Message-ID: <53767922.7000207@suse.de> (raw)
In-Reply-To: <5376356A.9000809@ozlabs.ru>
On 16.05.14 17:57, Alexey Kardashevskiy wrote:
> On 05/17/2014 12:16 AM, Alexander Graf wrote:
>> On 15.05.14 13:28, Alexey Kardashevskiy wrote:
>>> Modern Linux kernels support last POWERPC CPUs so when a kernel boots,
>>> in most cases it can find a matching cpu_spec in the kernel's cpu_specs
>>> list. However if the kernel is quite old, it may be missing a definition
>>> of the actual CPU. To provide an ability for old kernels to work on modern
>>> hardware, a Processor Compatibility Mode has been introduced
>>> by the PowerISA specification.
>>>
>>> From the hardware prospective, it is supported by the Processor
>>> Compatibility Register (PCR) which is defined in PowerISA. The register
>>> enables one of the compatibility modes (2.05/2.06/2.07).
>>> Since PCR is a hypervisor privileged register and cannot be
>>> accessed from the guest, the mode selection is done via
>>> ibm,client-architecture-support (CAS) RTAS call using which the guest
>>> specifies what "raw" and "architected" CPU versions it supports.
>>> QEMU works out the best match, changes a "cpu-version" property of
>>> every CPU and notifies the guest about the change by setting these
>>> properties in the buffer passed as a response on a custom H_CAS hypercall.
>>>
>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>> ---
>>> hw/ppc/spapr.c | 40 +++++++++++++++++++++++++
>>> hw/ppc/spapr_hcall.c | 83
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> trace-events | 5 ++++
>>> 3 files changed, 128 insertions(+)
>>>
>>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
>>> index a2c9106..a0882a1 100644
>>> --- a/hw/ppc/spapr.c
>>> +++ b/hw/ppc/spapr.c
>>> @@ -35,6 +35,7 @@
>>> #include "kvm_ppc.h"
>>> #include "mmu-hash64.h"
>>> #include "cpu-models.h"
>>> +#include "qom/cpu.h"
>>> #include "hw/boards.h"
>>> #include "hw/ppc/ppc.h"
>>> @@ -592,11 +593,50 @@ int spapr_h_cas_compose_response(target_ulong addr,
>>> target_ulong size)
>>> {
>>> void *fdt;
>>> sPAPRDeviceTreeUpdateHeader hdr = { .version_id = 1 };
>>> + CPUState *cs;
>>> + int smt = kvmppc_smt_threads();
>>> size -= sizeof(hdr);
>>> fdt = g_malloc0(size);
>>> _FDT((fdt_create(fdt, size)));
>>> + _FDT((fdt_begin_node(fdt, "cpus")));
>>> +
>>> + CPU_FOREACH(cs) {
>>> + PowerPCCPU *cpu = POWERPC_CPU(cs);
>>> + DeviceClass *dc = DEVICE_GET_CLASS(cpu);
>>> + int smpt = spapr_get_compat_smp_threads(cpu);
>>> + int i, index = ppc_get_vcpu_dt_id(cpu);
>>> + uint32_t servers_prop[smpt];
>>> + uint32_t gservers_prop[smpt * 2];
>>> + char tmp[32];
>>> +
>>> + if ((index % smt) != 0) {
>>> + continue;
>>> + }
>>> +
>>> + snprintf(tmp, 32, "%s@%x", dc->fw_name, index);
>>> + trace_spapr_cas_add_subnode(tmp);
>>> +
>>> + _FDT((fdt_begin_node(fdt, tmp)));
>>> + _FDT((fdt_property_cell(fdt, "cpu-version", cpu->cpu_version)));
>>> +
>>> + /* Build interrupt servers and gservers properties */
>>> + for (i = 0; i < smpt; i++) {
>>> + servers_prop[i] = cpu_to_be32(index + i);
>>> + /* Hack, direct the group queues back to cpu 0 */
>>> + gservers_prop[i*2] = cpu_to_be32(index + i);
>>> + gservers_prop[i*2 + 1] = 0;
>>> + }
>>> + _FDT((fdt_property(fdt, "ibm,ppc-interrupt-server#s",
>>> + servers_prop, sizeof(servers_prop))));
>>> + _FDT((fdt_property(fdt, "ibm,ppc-interrupt-gserver#s",
>>> + gservers_prop, sizeof(gservers_prop))));
>>> +
>>> + _FDT((fdt_end_node(fdt)));
>>> + }
>>> +
>>> + _FDT((fdt_end_node(fdt)));
>> Why is this so much code? Can we only replace full nodes?
> It is a diff tree, in only has properties to change.
So why do we change so much then? :)
>
>> Then please
>> extract the original CPU node creation into a function and just call it
>> from the original generation and from here.
>>
>> If we can also replace single properties I'd say we only need to override
>> cpu-version.
>
> Mmm. The user could run qemu with threads=8 on POWER8 with SLES11 which
> must not see 8 threads but it can update itself and reboot with the kernel
> which is aware of POWER8. You are saying we do not want to support that?
First off, I think that practically speaking people will want to use
2-thread granularity on POWER8 because that gives them the best load
exploitation on the system.
So if we just disable CPU nodes that would not be visible usually (there
was a disabled flag in cpu nodes, right?) for threads that are
incompatible with a new CAS mode, we can then remove the disabled flag
when the guest accepts more threads again.
That means we could expose 8 threads (POWER8), guest only supports 2
threads (POWER6), so we waste 6 threads. But the remaining 2 will be
fast ;). We basically degrade the system to SMT2 mode.
What does pHyp do here?
Alex
next prev parent reply other threads:[~2014-05-16 20:46 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-15 11:28 [Qemu-devel] [PATCH 0/9] spapr: Enable ibm, client-architecture-support Alexey Kardashevskiy
2014-05-15 11:28 ` [Qemu-devel] [PATCH 1/9] kvm: add set_one_reg/get_one_reg helpers Alexey Kardashevskiy
2014-05-15 11:28 ` [Qemu-devel] [PATCH 2/9] target-ppc: Add "compat" CPU option Alexey Kardashevskiy
2014-05-15 11:28 ` [Qemu-devel] [PATCH 3/9] spapr: Move server# property out of skeleton fdt Alexey Kardashevskiy
2014-05-15 11:28 ` [Qemu-devel] [PATCH 4/9] target-ppc: Implement "compat" CPU option Alexey Kardashevskiy
2014-05-16 14:05 ` Alexander Graf
2014-05-16 15:17 ` Alexey Kardashevskiy
2014-05-16 20:47 ` Alexander Graf
2014-05-21 6:57 ` Alexey Kardashevskiy
2014-05-21 7:29 ` Alexander Graf
2014-05-21 7:59 ` Alexey Kardashevskiy
2014-05-21 8:00 ` Alexander Graf
2014-05-21 8:08 ` Alexey Kardashevskiy
2014-05-15 11:28 ` [Qemu-devel] [PATCH 5/9] target-ppc: Define Processor Compatibility Masks Alexey Kardashevskiy
2014-05-15 11:28 ` [Qemu-devel] [PATCH 6/9] spapr: Add ibm, client-architecture-support call Alexey Kardashevskiy
2014-05-19 3:47 ` [Qemu-devel] [Qemu-ppc] " Nikunj A Dadhania
2014-05-15 11:28 ` [Qemu-devel] [PATCH 7/9] spapr: Limit threads per core according to current compatibility mode Alexey Kardashevskiy
2014-05-16 14:09 ` Alexander Graf
2014-05-15 11:28 ` [Qemu-devel] [PATCH 8/9] spapr: Implement processor compatibility in ibm, client-architecture-support Alexey Kardashevskiy
2014-05-16 14:16 ` Alexander Graf
2014-05-16 15:57 ` Alexey Kardashevskiy
2014-05-16 20:46 ` Alexander Graf [this message]
2014-05-17 1:45 ` Alexey Kardashevskiy
2014-05-19 3:09 ` Alexey Kardashevskiy
2014-05-19 9:01 ` Alexander Graf
2014-05-15 11:28 ` [Qemu-devel] [PATCH 9/9] KVM: PPC: Enable compatibility mode Alexey Kardashevskiy
2014-05-16 14:18 ` Alexander Graf
2014-05-16 14:27 ` Alexey Kardashevskiy
2014-05-16 14:35 ` Alexander Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53767922.7000207@suse.de \
--to=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).