On 2020-11-02 03:12, Peng Liang wrote:
Hi Marc,
Sorry for my late reply.
On 10/31/2020 9:25 PM, Marc Zyngier wrote:
Hi Peng,
[+Will, as we hacked the new ECE (Ectoplasmic Control Enclosure)
together]
On Sat, 31 Oct 2020 07:03:02 +0000,
Peng Liang <liangpeng10@xxxxxxxxxx> wrote:
[...]
I found that the different register and the different field between
source and destination is ID_AA64PFR0_EL1.CSV2. I searched in git log
and found that the commit e1026237f9067 ("KVM: arm64: Set CSV2 for
guests on hardware unaffected by Spectre-v2") may be the cause of the
failure?
Thanks for the thorough analysis. Yes, this could well be the issue if
CSV2 isn't explicitly set at the source, and is now set on the target.
For confirmation, what is the value of ID_AA64PFR0_EL1.CSV2 on the
host? What does /sys/devices/system/cpu/vulnerabilities/spectre_v2
contain?
On host:
ID_AA64PFR0_EL1.CSV2: 0
/sys/devices/system/cpu/vulnerabilities/spectre_v2: Not affected
Right. I guess this system supports WA1 and reports "not affected".
So do we need to make it possible to migrate VMs between Linux v5.9
and
Linux v5.10-rc1 with QEMU?
We should fix the migration from 5.9 to 5.10. I don't plan to support
migrating in the other direction, which is consistent with new sysregs
and features appearing in the sysreg space over time (although I would
expect 5.9 -> 5.10 -> 5.9 to work once we fix this issue).
BTW, there always be new sysregs/features introduced to kernel over
time. If that happened, do we need to make migration successful from a
older version without the new sysregs/features? I think there is no
reason to not allow migration from old version to new version if the
source end and the destination end have the same hardware just because
old version doesn't expose some sysregs/features to guest but new
version does.
What if kernel 5.11 adds unconditional support for a feature and that
results in a new sysreg gets exposed? How do you plan to restore this
guest on 5.10?
In may work in limited cases, but it doesn't in general. To make that
work, you'd need to implement some explicit buy-in from userspace on
each and every feature that gets added to the hypervisor. This is
completely impractical, and I have no desire to support it.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
