Re: VM live migration failed from Linux v5.9 to Linux v5.10-rc1

[Marc Zyngier <maz@kernel.org>]

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@huawei.com> 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@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm