|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
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?
|[Prev in Thread]||Current Thread||[Next in Thread]|