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

Re: Assertion failed at arch/x86/genapic/x2apic.c:38 on S3 resume nested in KVM on AMD



On Thu, Aug 08, 2024 at 01:22:30PM +0200, Jan Beulich wrote:
> On 23.07.2024 16:28, Marek Marczykowski-Górecki wrote:
> > I'm observing a crash like the one below when trying to resume from S3.
> > It happens on Xen nested in KVM (QEMU 9.0, Linux 6.9.3) but only on AMD.
> > The very same software stack on Intel works just fine. QEMU is running
> > with "-cpu host,+svm,+invtsc -machine q35,kernel-irqchip=split -device
> > amd-iommu,intremap=on -smp 2" among others.
> > 
> >     (XEN) Preparing system for ACPI S3 state.
> >     (XEN) Disabling non-boot CPUs ...
> >     (XEN) Broke affinity for IRQ1, new: {0-1}
> >     (XEN) Broke affinity for IRQ20, new: {0-1}
> >     (XEN) Broke affinity for IRQ22, new: {0-1}
> >     (XEN) Entering ACPI S3 state.
> >     (XEN) Finishing wakeup from ACPI S3 state.
> >     (XEN) Enabling non-boot CPUs  ...
> >     (XEN) Assertion 'cpumask_test_cpu(this_cpu, per_cpu(cluster_cpus, 
> > this_cpu))' failed at arch/x86/genapic/x2apic.c:38
> >     (XEN) ----[ Xen-4.20  x86_64  debug=y  Not tainted ]----
> >     (XEN) CPU:    1
> >     (XEN) RIP:    e008:[<ffff82d04028862b>] 
> > x2apic.c#init_apic_ldr_x2apic_cluster+0x8a/0x1b9
> >     (XEN) RFLAGS: 0000000000010096   CONTEXT: hypervisor
> >     (XEN) rax: ffff830278a25f50   rbx: 0000000000000001   rcx: 
> > ffff82d0405e1700
> >     (XEN) rdx: 0000003233412000   rsi: ffff8302739da2d8   rdi: 
> > 0000000000000000
> >     (XEN) rbp: 00000000000000c8   rsp: ffff8302739d7e78   r8:  
> > 0000000000000001
> >     (XEN) r9:  ffff8302739d7fa0   r10: 0000000000000001   r11: 
> > 0000000000000000
> >     (XEN) r12: 0000000000000001   r13: 0000000000000001   r14: 
> > 0000000000000000
> >     (XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 
> > 00000000007506e0
> >     (XEN) cr3: 000000007fa7a000   cr2: 0000000000000000
> >     (XEN) fsb: 0000000000000000   gsb: 0000000000000000   gss: 
> > 0000000000000000
> >     (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
> >     (XEN) Xen code around <ffff82d04028862b> 
> > (x2apic.c#init_apic_ldr_x2apic_cluster+0x8a/0x1b9):
> >     (XEN)  cf 82 ff ff eb b7 0f 0b <0f> 0b 48 8d 05 9c fc 33 00 48 8b 0d a5 
> > 0a 35 00
> >     (XEN) Xen stack trace from rsp=ffff8302739d7e78:
> >     (XEN)    0000000000000000 00000000000000c8 0000000000000001 
> > 0000000000000001
> >     (XEN)    0000000000000000 ffff82d0402f1d83 ffff8302739d7fff 
> > 00000000000000c8
> >     (XEN)    0000000000000001 0000000000000001 ffff82d04031adb9 
> > 0000000000000001
> >     (XEN)    0000000000000000 0000000000000000 0000000000000000 
> > ffff82d040276677
> >     (XEN)    0000000000000000 0000000000000000 0000000000000000 
> > 0000000000000000
> >     (XEN)    ffff88810037c000 0000000000000001 0000000000000246 
> > deadbeefdeadf00d
> >     (XEN)    0000000000000001 aaaaaaaaaaaaaaaa 0000000000000000 
> > ffffffff811d130a
> >     (XEN)    deadbeefdeadf00d deadbeefdeadf00d deadbeefdeadf00d 
> > 0000010000000000
> >     (XEN)    ffffffff811d130a 000000000000e033 0000000000000246 
> > ffffc900400b3ef8
> >     (XEN)    000000000000e02b 000000000000beef 000000000000beef 
> > 000000000000beef
> >     (XEN)    000000000000beef 0000e01000000001 ffff8302739de000 
> > 0000003233412000
> >     (XEN)    00000000007506e0 0000000000000000 0000000000000000 
> > 0000000200000000
> >     (XEN)    0000000000000002
> >     (XEN) Xen call trace:
> >     (XEN)    [<ffff82d04028862b>] R 
> > x2apic.c#init_apic_ldr_x2apic_cluster+0x8a/0x1b9
> >     (XEN)    [<ffff82d0402f1d83>] S setup_local_APIC+0x26/0x449
> >     (XEN)    [<ffff82d04031adb9>] S start_secondary+0x1c4/0x37a
> >     (XEN)    [<ffff82d040276677>] S __high_start+0x87/0xd0
> >     (XEN) 
> >     (XEN) 
> >     (XEN) ****************************************
> >     (XEN) Panic on CPU 1:
> >     (XEN) Assertion 'cpumask_test_cpu(this_cpu, per_cpu(cluster_cpus, 
> > this_cpu))' failed at arch/x86/genapic/x2apic.c:38
> >     (XEN) ****************************************
> 
> Would you mind giving the patch below a try?

Yes, this seems to fix the issue, thanks!

> Jan
> 
> x86/x2APIC: correct cluster tracking upon CPUs going down for S3
> 
> Downing CPUs for S3 is somewhat special: Since we can expect the system
> to come back up in exactly the same hardware configuration, per-CPU data
> for the secondary CPUs isn't de-allocated (and then cleared upon re-
> allocation when the CPUs are being brought back up). Therefore the
> cluster_cpus per-CPU pointer will retain its value for all CPUs other
> than the final one in a cluster (i.e. in particular for all CPUs in the
> same cluster as CPU0). That, however, is in conflict with the assertion
> early in init_apic_ldr_x2apic_cluster().
> 
> Note that the issue is avoided on Intel hardware, where we park CPUs
> instead of bringing them down.

I wonder why I don't hit this issue on baremetal AMD, only on nested.
Anyway,

Tested-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>

> Extend the bypassing of the freeing to the suspend case, thus making
> suspend/resume also a tiny bit faster.
> 
> Fixes: 2e6c8f182c9c ("x86: distinguish CPU offlining from CPU removal")
> Reported-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> --- a/xen/arch/x86/genapic/x2apic.c
> +++ b/xen/arch/x86/genapic/x2apic.c
> @@ -228,7 +228,8 @@ static int cf_check update_clusterinfo(
>      case CPU_UP_CANCELED:
>      case CPU_DEAD:
>      case CPU_REMOVE:
> -        if ( park_offline_cpus == (action != CPU_REMOVE) )
> +        if ( park_offline_cpus == (action != CPU_REMOVE) ||
> +             system_state == SYS_STATE_suspend )
>              break;
>          if ( per_cpu(cluster_cpus, cpu) )
>          {
> 
> 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.