[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] POWER8 <-> POWER8E migration changed/broken in ppc-for.2.
Re: [Qemu-ppc] POWER8 <-> POWER8E migration changed/broken in ppc-for.2.10. Intended?
Wed, 9 Aug 2017 15:05:24 +1000
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
> 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
> 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_!
Description: PGP signature