All of lore.kernel.org
 help / color / mirror / Atom feed
* Crash with your meltdown patches
@ 2018-03-01 17:05 Juergen Gross
  2018-03-01 17:48 ` Andrew Cooper
  0 siblings, 1 reply; 7+ messages in thread
From: Juergen Gross @ 2018-03-01 17:05 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Andrew Cooper, xen-devel

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?


Juergen

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Crash with your meltdown patches
  2018-03-01 17:05 Crash with your meltdown patches Juergen Gross
@ 2018-03-01 17:48 ` Andrew Cooper
  2018-03-01 18:23   ` Juergen Gross
  0 siblings, 1 reply; 7+ messages in thread
From: Andrew Cooper @ 2018-03-01 17:48 UTC (permalink / raw)
  To: Juergen Gross, Jan Beulich; +Cc: xen-devel

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?

~Andrew

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Crash with your meltdown patches
  2018-03-01 17:48 ` Andrew Cooper
@ 2018-03-01 18:23   ` Juergen Gross
  2018-03-01 18:26     ` Andrew Cooper
  2018-03-02  7:44     ` Jan Beulich
  0 siblings, 2 replies; 7+ messages in thread
From: Juergen Gross @ 2018-03-01 18:23 UTC (permalink / raw)
  To: Andrew Cooper, Jan Beulich; +Cc: xen-devel

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;
 }



Juergen


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

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: Crash with your meltdown patches
  2018-03-01 18:23   ` Juergen Gross
@ 2018-03-01 18:26     ` Andrew Cooper
  2018-03-01 18:36       ` Juergen Gross
  2018-03-02  7:44     ` Jan Beulich
  1 sibling, 1 reply; 7+ messages in thread
From: Andrew Cooper @ 2018-03-01 18:26 UTC (permalink / raw)
  To: Juergen Gross, Jan Beulich; +Cc: xen-devel

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Crash with your meltdown patches
  2018-03-01 18:26     ` Andrew Cooper
@ 2018-03-01 18:36       ` Juergen Gross
  0 siblings, 0 replies; 7+ messages in thread
From: Juergen Gross @ 2018-03-01 18:36 UTC (permalink / raw)
  To: Andrew Cooper, Jan Beulich; +Cc: xen-devel

On 01/03/18 19:26, Andrew Cooper wrote:
> 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.

Right, that's what I wrote.

In the end I'm fine it is working again, as the global bit shouldn't
matter at all for my series - I'm disabling cr4.pge while running a
XPTI domain.


Juergen


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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Crash with your meltdown patches
  2018-03-01 18:23   ` Juergen Gross
  2018-03-01 18:26     ` Andrew Cooper
@ 2018-03-02  7:44     ` Jan Beulich
  2018-03-02  8:05       ` Jan Beulich
  1 sibling, 1 reply; 7+ messages in thread
From: Jan Beulich @ 2018-03-02  7:44 UTC (permalink / raw)
  To: Juergen Gross; +Cc: Andrew Cooper, xen-devel

>>> On 01.03.18 at 19:23, <jgross@suse.com> wrote:
> --- 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));

I agree with the change to the ASSERT(), but why the dropping of
the "else"?

Jan


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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Crash with your meltdown patches
  2018-03-02  7:44     ` Jan Beulich
@ 2018-03-02  8:05       ` Jan Beulich
  0 siblings, 0 replies; 7+ messages in thread
From: Jan Beulich @ 2018-03-02  8:05 UTC (permalink / raw)
  To: Juergen Gross; +Cc: Andrew Cooper, xen-devel

>>> On 02.03.18 at 08:44, <JBeulich@suse.com> wrote:
>>>> On 01.03.18 at 19:23, <jgross@suse.com> wrote:
>> --- 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));
> 
> I agree with the change to the ASSERT(), but why the dropping of
> the "else"?

Wait, no, I do not agree: If we change this assertion, we merely
hide a problem elsewhere. We are supposed to only write cloned
page tables here, and all such writes happen with the global bit
clear. Hence if we find an entry with a set global bit, we must be
attempting to modify a non-cloned PTE. I'll have to look into this
more closely.

Jan


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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2018-03-02  8:05 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-01 17:05 Crash with your meltdown patches Juergen Gross
2018-03-01 17:48 ` Andrew Cooper
2018-03-01 18:23   ` Juergen Gross
2018-03-01 18:26     ` Andrew Cooper
2018-03-01 18:36       ` Juergen Gross
2018-03-02  7:44     ` Jan Beulich
2018-03-02  8:05       ` Jan Beulich

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.