Forward migration broken down since virt-4.2 machine type

Forward migration broken down since virt-4.2 machine type

[Ying Fang]

Hi Richard,

Recently we are doing some tests on forward migration based on
arm virt machine. And we found the patch below breaks forward
migration compatibility from virt-4.2 to virt-5.0 above machine
type. The patch which breaks this down given by git bisect is

commit f9506e162c33e87b609549157dd8431fcc732085
target/arm: Remove ARM_FEATURE_VFP*

QEMU may get crashed on the destination host loading cpu state.
Here goes my question since I am not familiar with the VFP feature.
1: Should we keep the forward migration compatibility here ?
2: If so how can we fixed it ?

Below is the crash stack:
Thread 1 "qemu-system-aar" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 712330]
armv7m_nvic_neg_prio_requested (opaque=0x0, secure=secure@entry=false) 
at  qemu/hw/intc/armv7m_nvic.c:391
391	    if (s->cpu->env.v7m.faultmask[secure]) {
#0  armv7m_nvic_neg_prio_requested (opaque=0x0, 
secure=secure@entry=false) at  qemu/hw/intc/armv7m_nvic.c:391
#1  0x0000aaae6f766510 in arm_v7m_mmu_idx_for_secstate_and_priv 
(env=0xaaae73456780, secstate=false, priv=true) at 
qemu/target/arm/m_helper.c:2711
#2  0x0000aaae6f7163f0 in arm_mmu_idx_el (env=env@entry=0xaaae73456780, 
el=el@entry=1) at  qemu/target/arm/helper.c:12386
#3  0x0000aaae6f717000 in rebuild_hflags_internal (env=0xaaae73456780) 
at  qemu/target/arm/helper.c:12611
#4  arm_rebuild_hflags (env=env@entry=0xaaae73456780) at 
qemu/target/arm/helper.c:12624
#5  0x0000aaae6f722940 in cpu_post_load (opaque=0xaaae7344ceb0, 
version_id=<optimized out>) at  qemu/target/arm/machine.c:767
#6  0x0000aaae6f9e0e78 in vmstate_load_state (f=f@entry=0xaaae73020260, 
vmsd=0xaaae6fe93178 <vmstate_arm_cpu>, opaque=0xaaae7344ceb0, 
version_id=22) at migration/vmstate.c:168
#7  0x0000aaae6f9d9858 in vmstate_load (f=f@entry=0xaaae73020260, 
se=se@entry=0xaaae7302f750) at migration/savevm.c:885
#8  0x0000aaae6f9dab90 in qemu_loadvm_section_start_full 
(f=f@entry=0xaaae73020260, mis=0xaaae72fb88a0) at migration/savevm.c:2302
#9  0x0000aaae6f9dd248 in qemu_loadvm_state_main 
(f=f@entry=0xaaae73020260, mis=mis@entry=0xaaae72fb88a0) at 
migration/savevm.c:2486
#10 0x0000aaae6f9de3bc in qemu_loadvm_state (f=0xaaae73020260) at 
migration/savevm.c:2560
#11 0x0000aaae6f9d489c in process_incoming_migration_co 
(opaque=<optimized out>) at migration/migration.c:461
#12 0x0000aaae6fb59850 in coroutine_trampoline (i0=<optimized out>, 
i1=<optimized out>) at util/coroutine-ucontext.c:115
#13 0x0000fffdd6c16030 in ?? () from target:/usr/lib64/libc.so.6

#0  armv7m_nvic_neg_prio_requested (opaque=0x0, 
secure=secure@entry=false) at  qemu/hw/intc/armv7m_nvic.c:391
(gdb) p	s
$4 = (NVICState *) 0x0

Thanks.
Ying

Re: Forward migration broken down since virt-4.2 machine type

[Ying Fang]

ping

On 6/4/2020 4:51 PM, Ying Fang wrote:
> Hi Richard,
> 
> Recently we are doing some tests on forward migration based on
> arm virt machine. And we found the patch below breaks forward
> migration compatibility from virt-4.2 to virt-5.0 above machine
> type. The patch which breaks this down given by git bisect is
> 
> commit f9506e162c33e87b609549157dd8431fcc732085
> target/arm: Remove ARM_FEATURE_VFP*
> 
> QEMU may get crashed on the destination host loading cpu state.
> Here goes my question since I am not familiar with the VFP feature.
> 1: Should we keep the forward migration compatibility here ?
> 2: If so how can we fixed it ?
> 
> Below is the crash stack:
> Thread 1 "qemu-system-aar" received signal SIGSEGV, Segmentation fault.
> [Switching to LWP 712330]
> armv7m_nvic_neg_prio_requested (opaque=0x0, secure=secure@entry=false) 
> at  qemu/hw/intc/armv7m_nvic.c:391
> 391        if (s->cpu->env.v7m.faultmask[secure]) {
> #0  armv7m_nvic_neg_prio_requested (opaque=0x0, 
> secure=secure@entry=false) at  qemu/hw/intc/armv7m_nvic.c:391
> #1  0x0000aaae6f766510 in arm_v7m_mmu_idx_for_secstate_and_priv 
> (env=0xaaae73456780, secstate=false, priv=true) at 
> qemu/target/arm/m_helper.c:2711
> #2  0x0000aaae6f7163f0 in arm_mmu_idx_el (env=env@entry=0xaaae73456780, 
> el=el@entry=1) at  qemu/target/arm/helper.c:12386
> #3  0x0000aaae6f717000 in rebuild_hflags_internal (env=0xaaae73456780) 
> at  qemu/target/arm/helper.c:12611
> #4  arm_rebuild_hflags (env=env@entry=0xaaae73456780) at 
> qemu/target/arm/helper.c:12624
> #5  0x0000aaae6f722940 in cpu_post_load (opaque=0xaaae7344ceb0, 
> version_id=<optimized out>) at  qemu/target/arm/machine.c:767
> #6  0x0000aaae6f9e0e78 in vmstate_load_state (f=f@entry=0xaaae73020260, 
> vmsd=0xaaae6fe93178 <vmstate_arm_cpu>, opaque=0xaaae7344ceb0, 
> version_id=22) at migration/vmstate.c:168
> #7  0x0000aaae6f9d9858 in vmstate_load (f=f@entry=0xaaae73020260, 
> se=se@entry=0xaaae7302f750) at migration/savevm.c:885
> #8  0x0000aaae6f9dab90 in qemu_loadvm_section_start_full 
> (f=f@entry=0xaaae73020260, mis=0xaaae72fb88a0) at migration/savevm.c:2302
> #9  0x0000aaae6f9dd248 in qemu_loadvm_state_main 
> (f=f@entry=0xaaae73020260, mis=mis@entry=0xaaae72fb88a0) at 
> migration/savevm.c:2486
> #10 0x0000aaae6f9de3bc in qemu_loadvm_state (f=0xaaae73020260) at 
> migration/savevm.c:2560
> #11 0x0000aaae6f9d489c in process_incoming_migration_co 
> (opaque=<optimized out>) at migration/migration.c:461
> #12 0x0000aaae6fb59850 in coroutine_trampoline (i0=<optimized out>, 
> i1=<optimized out>) at util/coroutine-ucontext.c:115
> #13 0x0000fffdd6c16030 in ?? () from target:/usr/lib64/libc.so.6
> 
> #0  armv7m_nvic_neg_prio_requested (opaque=0x0, 
> secure=secure@entry=false) at  qemu/hw/intc/armv7m_nvic.c:391
> (gdb) p    s
> $4 = (NVICState *) 0x0
> 
> Thanks.
> Ying