Re: [Xen-devel] Crash with your meltdown patches

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 01/03/18 18:23, Juergen Gross wrote:
> On 01/03/18 18:48, Andrew Cooper wrote:
>> On 01/03/18 17:05, Juergen Gross wrote:
>>> Jan,
>>>
>>> I just rebased my patch series for speeding up XPTI to current
>>> staging. This included your pending speedup series. I'm now seeing
>>> a crash with the first patch of yours:
>>>
>>> (XEN) Intel VT-d Queued Invalidation enabled.
>>> (XEN) Intel VT-d Interrupt Remapping enabled.
>>> (XEN) Intel VT-d Posted Interrupt not enabled.
>>> (XEN) Intel VT-d Shared EPT tables not enabled.
>>> (XEN) I/O virtualisation enabled
>>> (XEN)  - Dom0 mode: Relaxed
>>> (XEN) Interrupt remapping enabled
>>> (XEN) Assertion 'l1e_get_flags(*pl1e) == flags' failed at smpboot.c:750
>>> (XEN) ----[ Xen-4.11-unstable  x86_64  debug=y   Tainted:  C   ]----
>>> (XEN) CPU:    0
>>> (XEN) RIP:    e008:[<ffff82d08029fe68>] smpboot.c#clone_mapping+0x656/0x6c0
>>> (XEN) RFLAGS: 0000000000010287   CONTEXT: hypervisor
>>> (XEN) rax: 00000000000dbbab   rbx: 0000000000000d58   rcx: 0000000000000163
>>> (XEN) rdx: 0000000000800163   rsi: 0000000000800063   rdi: 00000007c7ffffff
>>> (XEN) rbp: ffff82d080477d58   rsp: ffff82d080477d18   r8:  0000000000217fdd
>>> (XEN) r9:  ffffffffffffffff   r10: 0000000217fdd000   r11: 0000000000000163
>>> (XEN) r12: ffff83021bfd9d58   r13: ffff8300dba62010   r14: 0000000000800163
>>> (XEN) r15: ffff830217fde828   cr0: 000000008005003b   cr4: 00000000001506e0
>>> (XEN) cr3: 00000000dba66000   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 <ffff82d08029fe68>
>>> (smpboot.c#clone_mapping+0x656/0x6c0):
>>> (XEN)  74 02 0f 0b 39 d6 74 56 <0f> 0b 41 81 e6 ff 0e 00 00 48 8b 45 c8
>>> 48 c1 e0
>>> (XEN) Xen stack trace from rsp=ffff82d080477d18:
>>> (XEN)    ffff82d0805b0020 00000000000dbbab ffff82d080477d48 0000000000008000
>>> (XEN)    ffff830217fde000 0000000000000000 00000007c7ffffff ffff82ffffffffff
>>> (XEN)    ffff82d080477d98 ffff82d0802a0085 ffff82d080477db8 ffff82d080477fff
>>> (XEN)    ffff830217ff2f60 ffff82d0805b0020 ffff82d0805b0020 0000000000000003
>>> (XEN)    ffff82d080477db8 ffff82d0804083c7 ffff82d080477fff ffff82d080477fff
>>> (XEN)    ffff82d080477ee8 ffff82d080407be0 0000000000000000 00000000003b0180
>>> (XEN)    00000000000001dc 00000000000001f1 00000000000001fe 000000000000016a
>>> (XEN)    0000000000000002 0000000000000002 0000000000000002 0000000000000001
>>> (XEN)    0000000000000001 0000000000000001 0000000000000001 0000000000000000
>>> (XEN)    00000000cee00000 000000000021ee00 000000021bfdc000 0000000000000000
>>> (XEN)    ffff83000008fc30 ffff82d000000003 0000000200000003 0000000001a9b000
>>> (XEN)    ffff83000008ff30 ffff83000008ffb0 0000000000000000 0000000000000000
>>> (XEN)    0000000800000000 000000010000006e 0000000000000003 00000000000002f8
>>> (XEN)    0000000000000000 0000000000000000 000000000000180a 00000000cbf65b98
>>> (XEN)    0000000000000001 00000000d287d018 0000000000000000 ffff82d0802000f3
>>> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>> (XEN)    0000000000000000 0000000c00000000 732dccb6003dccb3 003dc71000477f74
>>> (XEN)    003dccb50008ffa2 732dccb60000000c 003dccb300000000 00477fa00008ffad
>>> (XEN)    0008ffad003dc776 00000004003dccaf 00477fb80008ff01 0000000c003dc776
>>> (XEN) Xen call trace:
>>> (XEN)    [<ffff82d08029fe68>] smpboot.c#clone_mapping+0x656/0x6c0
>>> (XEN)    [<ffff82d0802a0085>] smpboot.c#setup_cpu_root_pgt+0x1b3/0x2a1
>>> (XEN)    [<ffff82d0804083c7>] smp_prepare_cpus+0x87/0x38a
>>> (XEN)    [<ffff82d080407be0>] __start_xen+0x2029/0x2623
>>> (XEN)    [<ffff82d0802000f3>] __high_start+0x53/0x60
>>>
>>> I suspect Andrew's patch 422588e88511d17984544c0f017a927de3315290 might
>>> be the cause, as my series was based on staging from Feb 14th and this
>>> patch seems the only one related to the crash.
>>>
>>> Do you have an idea how to fix the problem?
>> Which mapping is attempting to be cloned at this point?
> The idt.
>
> This modification lets it boot again:
>
> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> index 6b2c0b3ac5..d03eb608d9 100644
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -747,10 +747,9 @@ static int clone_mapping(const void *ptr,
> root_pgentry_t *rpt)
>      if ( l1e_get_flags(*pl1e) & _PAGE_PRESENT )
>      {
>          ASSERT(l1e_get_pfn(*pl1e) == pfn);
> -        ASSERT(l1e_get_flags(*pl1e) == flags);
> +        ASSERT((l1e_get_flags(*pl1e) & ~_PAGE_GLOBAL) == flags);
>      }
> -    else
> -        l1e_write(pl1e, l1e_from_pfn(pfn, flags));
> +    l1e_write(pl1e, l1e_from_pfn(pfn, flags));
>
>      return 0;
>  }

Oh, in which case that will be the middle of Jan's speedup series, which
plays with global handling.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel