qemu-ppc
[Top][All Lists]
Advanced

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

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


From: Daniel Henrique Barboza
Subject: Re: [Qemu-ppc] POWER8 <-> POWER8E migration changed/broken in ppc-for.2.10. Intended?
Date: Tue, 8 Aug 2017 20:40:05 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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?



Thanks,


Daniel

reply via email to

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