qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] target-ppc: Add POWER8E_v2.1 CPU model.


From: Alexey Kardashevskiy
Subject: Re: [Qemu-devel] [PATCH] target-ppc: Add POWER8E_v2.1 CPU model.
Date: Mon, 13 Jul 2015 13:11:03 +1000
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1

On 07/10/2015 07:19 PM, Andrea Bolognani wrote:
On Fri, 2015-07-10 at 15:19 +1000, Alexey Kardashevskiy wrote:

If I'm reading the kernel source[1] correctly, there are actually
subtle
differences other than the number of cores:

    #define CPU_FTRS_POWER8 (/* Bunch of features here */)
    #define CPU_FTRS_POWER8E (CPU_FTRS_POWER8 | CPU_FTR_PMAO_BUG)

POWER8E was the first family of POWER8. Some revisions of POWER8E
have this
bug. The bug is that if we migrate from a good POWER8 to POWER8 with
this
bug, perf counters will stop working as the source kernel did not
detect
broken CPU and did not enable a workaround. We do not really know how
many
of this chips are out there (not many I believe) and how many have
this
bug. And also I guess that more people will be annoyed by inability
to
migrate rather than by broken perf.

I'd leave migration enabled but it is worth mentioning somewhere in
user's
guide that if the user migrates a guest to POWER8E with the specific
PVR,
perf might break.

David said we might be able to just apply the kernel PMAO workaround
unconditionally, which would of course be great. Even if that turns out
not to be possible, I agree with you that allowing migration is more
important than not breaking performance monitoring, and documenting
this properly should be enough.

    #define CPU_FTRS_POWER8_DD1 (CPU_FTRS_POWER8 & ~CPU_FTR_DBELL)

This bug appears in POWER8E and POWER8 1.0 ("DD1"). The bug is that
when a
CPU thread wakes up after nap because of doorbell message, the
doorbell
interrupt is not pending. Guests cannot do nap themselves (they use
H_CEDE
hypercall for this), when a thread wakes up, it wakes in the host
context
so there is nothing to handle in the guest, it is purely for KVM to
workaround.

Great news!

So the PVR matching, as done currently in QEMU, will include
POWER8DD1
but exclude POWER8NVL, which according to to commit ddee09c0 and
the
code
above is absolutely identical to POWER8.

Yeah, we have to add 0x004c0000 into the POWER8 family as well, I'll
doublecheck.

Okay. libvirt will soon advertise just POWER8 instead of specific
models, and will consider the POWER8 guest CPU model to be compatible
with any host having a POWER8* CPU, using the same PVR values and
masks as the kernel. Once QEMU is updated to include POWER8NVL, the
behavior will be consistent across the stack.


Correct.

Just to be sure: the same applies to POWER7 as well, right? It
certainly looks so from both the kernel and QEMU code.

Right.


Thanks a lot for all the precious bits of information you've provided.

I've learnt a lot too :)


--
Alexey



reply via email to

[Prev in Thread] Current Thread [Next in Thread]