qemu-ppc
[Top][All Lists]
Advanced

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

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


From: Andrea Bolognani
Subject: Re: [Qemu-ppc] [PATCH] target-ppc: Add POWER8E_v2.1 CPU model.
Date: Fri, 10 Jul 2015 11:19:50 +0200

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.

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

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

Cheers.

-- 
Andrea Bolognani
Software Engineer - Virtualization Team



reply via email to

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