Re: [Qemu-ppc] POWER8 <-> POWER8E migration changed/broken in ppc-for.2.10. Intended?

[David Gibson]

On Tue, Aug 08, 2017 at 08:40:05PM -0300, Daniel Henrique Barboza wrote:
> Ping. Sorry about the delay, I got my hands full with Pegas and DD2 testing.
> 
> Is this too late to try to get this fixed for 2.10? As far as I've read in
> the discussion we
> had last month, quoting here the last messages:
> 
> ==============================
> > > > My intention here - right since the early days of KVM HV, was that
> > > > qemu would always put the PVR it really wanted into the sregs field.
> > > > KVM PR would then emulate a specific CPU based on that.  HV, not
> > > > having that option, would instead assess if the requested CPU was
> > > > close enough to the host CPU to get away with it.
> > > > 
> > > > But I guess, since qemu's haphazard handling of compat modes meant
> > > > that didn't really happen until now, we never properly tested that.
> > > > 
> > > > So, really I think the correct fix is in the kernel - to make it
> > > > accept a POWER8E PVR when hosted on a POWER8 and vice versa.
> > > What will we do for the power8 -> power9 migration?
> > Same thing, ideally.  We know POWER9 has a POWER8 compatibility mode,
> > so it's acceptable to set a POWER8 PVR on a POWER9 host.
> 
> Set P8's PVR to HV KVM on a P9 host, then read it back and see it is still
> P9's PVR - what is the point in such API? Or the point is in avoiding
> having differentiation between PR and HV in QEMU?
> 
> 
> =========================================
> 
> 
> It seems like this bug can be solved by changes in PR handling in the kernel
> (which would
> need to accept Power8E PVR when hosting on a POWER8 and vice-versa) or
> inside
> QEMU, which would required QEMU being aware of the guest being run in KVM HV
> or KVM PR.
> 
> I am not educated enough to say whether one design is better than the other,
> but I can
> say that a kernel side fix would also need a QEMU workaround to support any
> other
> kernel that doesn't have this capability. Is this a fair assessment?

Ugh.. it's been long enough since the rest of this thread that I've
forgotten the context.

Possibly we would need a qemu workaround yes - and that would need to
check for PR.  We have a more-or-less standard way of doing that
encoded in kvmppc_is_pr().  But that should *only* be used for
workarounds, if the kernel properly advertises a capability, qemu
should always use that and only if it can't determine fall back on
checking for PR.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

signature.asc
Description: PGP signature