* Re: PROBLEM: kernel panic xsave_init [not found] ` <20151019075618.GA22488@gmail.com> @ 2015-10-19 10:16 ` John Doe 2015-10-19 16:25 ` [Xen-devel] " Boris Ostrovsky 0 siblings, 1 reply; 9+ messages in thread From: John Doe @ 2015-10-19 10:16 UTC (permalink / raw) To: Ingo Molnar; +Cc: x86, linux-kernel, xen-devel On 19/10/2015 09:56, Ingo Molnar wrote: > > Please Cc: the Xen maintainers as this appears to be Xen specific. Also, please > Cc: linux-kernel@vger.kernel.org. > > Thanks, > > Ingo > > * John Doe <securef33d@gmail.com> wrote: > >> Hello, >> I get a kernel panic on QubesOS 3.0 during boot with kernels newer than >> 3.12.40-2, i tried several versions until the latest 4.3.0-rc5. It does >> boot properly with xsave=0 parameter. >> I attached the full console log with the stack trace. >> >> My machine runs a new i7-6700k skylake CPU on z170 chipset. >> >> I hope it can help. >> >> John. >> >> >> > >> about to get started... >> [ 0.000000] PAT configuration [0-7]: WB WT UC- UC WC WP UC UC >> [ 0.000000] Initializing cgroup subsys cpuset >> [ 0.000000] Initializing cgroup subsys cpu >> [ 0.000000] Initializing cgroup subsys cpuacct >> [ 0.000000] Linux version 4.1.9-6.pvops.qubes.x86_64 (user@release) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) ) #1 SMP Sat Oct 3 02:28:05 UTC 2015 >> [ 0.000000] Command line: placeholder root=/dev/mapper/qubes_dom0-root ro console=tty0 console=ttyS0,115200n8 rd.lvm.lv=qubes_dom0/root rd.luks.uuid=luks-nope >> [ 0.000000] Released 0 page(s) >> [ 0.000000] e820: BIOS-provided physical RAM map: >> [ 0.000000] Xen: [mem 0x0000000000000000-0x000000000009bfff] usable >> [ 0.000000] Xen: [mem 0x000000000009c800-0x00000000000fffff] reserved >> [ 0.000000] Xen: [mem 0x0000000000100000-0x0000000059f9afff] usable >> [ 0.000000] Xen: [mem 0x0000000059f9b000-0x0000000059f9bfff] ACPI NVS >> [ 0.000000] Xen: [mem 0x0000000059f9c000-0x0000000059fe5fff] reserved >> [ 0.000000] Xen: [mem 0x0000000059fe6000-0x000000005a038fff] usable >> [ 0.000000] Xen: [mem 0x000000005a039000-0x000000005a75afff] reserved >> [ 0.000000] Xen: [mem 0x000000005a75b000-0x0000000066b92fff] usable >> [ 0.000000] Xen: [mem 0x0000000066b93000-0x00000000677aafff] reserved >> [ 0.000000] Xen: [mem 0x00000000677ab000-0x0000000067f99fff] ACPI NVS >> [ 0.000000] Xen: [mem 0x0000000067f9a000-0x0000000067ffefff] ACPI data >> [ 0.000000] Xen: [mem 0x0000000067fff000-0x0000000067ffffff] usable >> [ 0.000000] Xen: [mem 0x0000000068000000-0x00000000680fffff] reserved >> [ 0.000000] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved >> [ 0.000000] Xen: [mem 0x00000000fe000000-0x00000000fe010fff] reserved >> [ 0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved >> [ 0.000000] Xen: [mem 0x00000000fed90000-0x00000000fed91fff] reserved >> [ 0.000000] Xen: [mem 0x00000000fee00000-0x00000000feefffff] reserved >> [ 0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved >> [ 0.000000] Xen: [mem 0x0000000100000000-0x0000000891ffffff] usable >> [ 0.000000] bootconsole [xenboot0] enabled >> [ 0.000000] NX (Execute Disable) protection: active >> [ 0.000000] SMBIOS 2.8 present. >> [ 0.000000] Hypervisor detected: Xen >> [ 0.000000] e820: last_pfn = 0x892000 max_arch_pfn = 0x400000000 >> [ 0.000000] e820: last_pfn = 0x68000 max_arch_pfn = 0x400000000 >> [ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff] >> [ 0.000000] init_memory_mapping: [mem 0x7d5200000-0x7d53fffff] >> [ 0.000000] init_memory_mapping: [mem 0x7c0000000-0x7d51fffff] >> [ 0.000000] init_memory_mapping: [mem 0x7a0000000-0x7bfffffff] >> [ 0.000000] init_memory_mapping: [mem 0x00100000-0x59f9afff] >> [ 0.000000] init_memory_mapping: [mem 0x59fe6000-0x5a038fff] >> [ 0.000000] init_memory_mapping: [mem 0x5a75b000-0x66b92fff] >> [ 0.000000] init_memory_mapping: [mem 0x67fff000-0x67ffffff] >> [ 0.000000] init_memory_mapping: [mem 0x100000000-0x79fffffff] >> [ 0.000000] init_memory_mapping: [mem 0x7d5400000-0x891ffffff] >> [ 0.000000] RAMDISK: [mem 0x08000000-0x0a815fff] >> [ 0.000000] ACPI: Early table checksum verification disabled >> [ 0.000000] ACPI: RSDP 0x00000000000F05B0 000024 (v02 ALASKA) >> [ 0.000000] ACPI: XSDT 0x0000000067A1F098 0000B4 (v01 ALASKA A M I 01072009 AMI 00010013) >> [ 0.000000] ACPI: FACP 0x0000000067A41B30 00010C (v05 ALASKA A M I 01072009 AMI 00010013) >> [ 0.000000] ACPI BIOS Warning (bug): Incorrect checksum in table [FACP] - 0x15, should be 0x49 (20150410/tbprint-211) >> [ 0.000000] ACPI: DSDT 0x0000000067A1F1E8 022943 (v02 ALASKA A M I 01072009 INTL 20120913) >> [ 0.000000] ACPI: FACS 0x0000000067F99F80 000040 >> [ 0.000000] ACPI: APIC 0x0000000067A41C40 0000BC (v03 ALASKA A M I 01072009 AMI 00010013) >> [ 0.000000] ACPI: FPDT 0x0000000067A41D00 000044 (v01 ALASKA A M I 01072009 AMI 00010013) >> [ 0.000000] ACPI: FIDT 0x0000000067A41D48 00009C (v01 ALASKA A M I 01072009 AMI 00010013) >> [ 0.000000] ACPI: MCFG 0x0000000067A41DE8 00003C (v01 ALASKA A M I 01072009 MSFT 00000097) >> [ 0.000000] ACPI: HPET 0x0000000067A41E28 000038 (v01 ALASKA A M I 01072009 AMI. 0005000B) >> [ 0.000000] ACPI: SSDT 0x0000000067A41E60 00036D (v01 SataRe SataTabl 00001000 INTL 20120913) >> [ 0.000000] ACPI: LPIT 0x0000000067A421D0 000094 (v01 INTEL SKL 00000000 MSFT 0000005F) >> [ 0.000000] ACPI: SSDT 0x0000000067A42268 00002B (v02 INTEL UsbCTabl 00001000 INTL 20120913) >> [ 0.000000] ACPI: DBGP 0x0000000067A42298 000034 (v01 INTEL 00000000 MSFT 0000005F) >> [ 0.000000] ACPI: DBG2 0x0000000067A422D0 000054 (v00 INTEL 00000000 MSFT 0000005F) >> [ 0.000000] ACPI: SSDT 0x0000000067A42328 000618 (v02 INTEL xh_rvp08 00000000 INTL 20120913) >> [ 0.000000] ACPI: AAFT 0x0000000067A42940 0004CE (v01 ALASKA OEMAAFT 01072009 MSFT 00000097) >> [ 0.000000] ACPI: SSDT 0x0000000067A42E10 005212 (v02 SaSsdt SaSsdt 00003000 INTL 20120913) >> [ 0.000000] ACPI: UEFI 0x0000000067A48028 000042 (v01 00000000 00000000) >> [ 0.000000] ACPI: SSDT 0x0000000067A48070 000E58 (v02 CpuRef CpuSsdt 00003000 INTL 20120913) >> [ 0.000000] ACPI: XMAR 0x0000000067A48EC8 0000A8 (v01 INTEL SKL 00000001 INTL 00000001) >> [ 0.000000] ACPI: ASF! 0x0000000067A48F70 0000A5 (v32 INTEL HCG 00000001 TFSM 000F4240) >> [ 0.000000] Setting APIC routing to Xen PV. >> [ 0.000000] NUMA turned off >> [ 0.000000] Faking a node at [mem 0x0000000000000000-0x0000000891ffffff] >> [ 0.000000] NODE_DATA(0) allocated [mem 0x7d54c9000-0x7d54dcfff] >> [ 0.000000] Zone ranges: >> [ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff] >> [ 0.000000] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] >> [ 0.000000] Normal [mem 0x0000000100000000-0x0000000891ffffff] >> [ 0.000000] Movable zone start for each node >> [ 0.000000] Early memory node ranges >> [ 0.000000] node 0: [mem 0x0000000000001000-0x000000000009bfff] >> [ 0.000000] node 0: [mem 0x0000000000100000-0x0000000059f9afff] >> [ 0.000000] node 0: [mem 0x0000000059fe6000-0x000000005a038fff] >> [ 0.000000] node 0: [mem 0x000000005a75b000-0x0000000066b92fff] >> [ 0.000000] node 0: [mem 0x0000000067fff000-0x0000000067ffffff] >> [ 0.000000] node 0: [mem 0x0000000100000000-0x0000000891ffffff] >> [ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x0000000891ffffff] >> [ 0.000000] p2m virtual area at ffffc90000000000, size is 4600000 >> [ 0.000000] Remapped 629821 page(s) >> [ 0.000000] ACPI: PM-Timer IO Port: 0x1808 >> [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) >> [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) >> [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) >> [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1]) >> [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1]) >> [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1]) >> [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1]) >> [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x08] high edge lint[0x1]) >> [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-119 >> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) >> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) >> [ 0.000000] Using ACPI (MADT) for SMP configuration information >> [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000 >> [ 0.000000] smpboot: Allowing 8 CPUs, 0 hotplug CPUs >> [ 0.000000] e820: [mem 0x68100000-0xdfffffff] available for PCI devices >> [ 0.000000] Booting paravirtualized kernel on Xen >> [ 0.000000] Xen version: 4.4.2 (preserve-AD) >> [ 0.000000] clocksource refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns >> [ 0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:8 nr_node_ids:1 >> [ 0.000000] PERCPU: Embedded 34 pages/cpu @ffff88086ee00000 s101080 r8192 d29992 u262144 >> [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 8226204 >> [ 0.000000] Policy zone: Normal >> [ 0.000000] Kernel command line: placeholder root=/dev/mapper/qubes_dom0-root ro console=tty0 console=ttyS0,115200n8 rd.lvm.lv=qubes_dom0/root rd.luks.uuid=luks-nope >> [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) >> (XEN) traps.c:2524:d0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. >> (XEN) traps.c:2524:d0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0802b3000 to 0xffffffff81772ed0. >> (XEN) traps.c:2524:d0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0802b3080 to 0xffffffff81775870. >> (XEN) traps.c:2524:d0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. >> (XEN) traps.c:2524:d0 Domain attempted WRMSR 0000000000000175 from 0xffff82d0802b7fc0 to 0x0000000000000000. >> (XEN) traps.c:2524:d0 Domain attempted WRMSR 0000000000000176 from 0xffff82d08021aff0 to 0xffffffff81775640. >> (XEN) traps.c:2524:d0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000034700 to 0x0000000000047700. >> [ 0.000000] general protection fault: 0000 [#1] SMP >> [ 0.000000] Modules linked in: >> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.9-6.pvops.qubes.x86_64 #1 >> [ 0.000000] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z170 Extreme4, BIOS P1.80 09/18/2015 >> [ 0.000000] task: ffffffff81c154c0 ti: ffffffff81c00000 task.ti: ffffffff81c00000 >> [ 0.000000] RIP: e030:[<ffffffff81d58fad>] [<ffffffff81d58fad>] xstate_enable_boot_cpu+0xde/0x288 >> [ 0.000000] RSP: e02b:ffffffff81c03de8 EFLAGS: 00010046 >> [ 0.000000] RAX: 000000000000001f RBX: 0000000000000008 RCX: 0000000000000000 >> [ 0.000000] RDX: 0000000000000000 RSI: 000000000000001f RDI: 0000000000042660 >> [ 0.000000] RBP: ffffffff81c03e48 R08: 0000000000000000 R09: ffffffff81c03df8 >> [ 0.000000] R10: ffffffff81c03dfc R11: 00000000ffffffff R12: 0000000000000004 >> [ 0.000000] R13: 0000000000000000 R14: ffffffff81c154c0 R15: ffff88086ee0b860 >> [ 0.000000] FS: 0000000000000000(0000) GS:ffff88086ee00000(0000) knlGS:0000000000000000 >> [ 0.000000] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 >> [ 0.000000] CR2: ffffc9000448f000 CR3: 0000000001c0e000 CR4: 0000000000042660 >> [ 0.000000] Stack: >> [ 0.000000] 0000000000000000 000002400000001f 0000000000000440 0000000000000008 >> [ 0.000000] ffff88086ee0a250 2008ee3531103c85 0000000080050033 0000000000000008 >> [ 0.000000] 0000000000000004 0000000000000000 ffffffff81c154c0 ffff88086ee0b860 >> [ 0.000000] Call Trace: >> [ 0.000000] [<ffffffff810237b0>] xsave_init+0x30/0x40 >> [ 0.000000] [<ffffffff8102201e>] fpu_init+0x9e/0xb0 >> [ 0.000000] [<ffffffff8102a1f4>] cpu_init+0x2f4/0x3e0 >> [ 0.000000] [<ffffffff81d54f05>] trap_init+0x2a2/0x312 >> [ 0.000000] [<ffffffff81d4def8>] start_kernel+0x25a/0x4bf >> [ 0.000000] [<ffffffff81d4da8e>] ? set_init_arg+0x55/0x55 >> [ 0.000000] [<ffffffff81d4d5ee>] x86_64_start_reservations+0x2a/0x2c >> [ 0.000000] [<ffffffff81d50a38>] xen_start_kernel+0x518/0x524 >> [ 0.000000] Code: 48 89 35 df 8a 17 00 48 39 f8 74 0f 65 48 89 3d 3a e0 2b 7e ff 14 25 f8 c4 c2 81 48 8b 05 c4 8a 17 00 31 c9 48 89 c2 48 c1 ea 20 <0f> 01 d1 48 8b 05 e5 aa fc ff a8 08 7 >> [ 0.000000] RIP [<ffffffff81d58fad>] xstate_enable_boot_cpu+0xde/0x288 >> [ 0.000000] RSP <ffffffff81c03de8> >> [ 0.000000] ---[ end trace 1f0c5608e200b15b ]--- >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! >> (XEN) Domain 0 crashed: rebooting machine in 5 seconds. > Here it is. I'm new to bug reporting, if you need anything just ask. Thank you, John. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xen-devel] PROBLEM: kernel panic xsave_init 2015-10-19 10:16 ` PROBLEM: kernel panic xsave_init John Doe @ 2015-10-19 16:25 ` Boris Ostrovsky 2015-10-20 9:51 ` Jan Beulich 0 siblings, 1 reply; 9+ messages in thread From: Boris Ostrovsky @ 2015-10-19 16:25 UTC (permalink / raw) To: John Doe, Ingo Molnar; +Cc: x86, linux-kernel, xen-devel, Jan Beulich On 10/19/2015 06:16 AM, John Doe wrote: >>> [ 0.000000] general protection fault: 0000 [#1] SMP >>> [ 0.000000] Modules linked in: >>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.9-6.pvops.qubes.x86_64 #1 >>> [ 0.000000] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z170 Extreme4, BIOS P1.80 09/18/2015 >>> [ 0.000000] task: ffffffff81c154c0 ti: ffffffff81c00000 task.ti: ffffffff81c00000 >>> [ 0.000000] RIP: e030:[<ffffffff81d58fad>] [<ffffffff81d58fad>] xstate_enable_boot_cpu+0xde/0x288 >>> [ 0.000000] RSP: e02b:ffffffff81c03de8 EFLAGS: 00010046 >>> [ 0.000000] RAX: 000000000000001f RBX: 0000000000000008 RCX: 0000000000000000 >>> [ 0.000000] RDX: 0000000000000000 RSI: 000000000000001f RDI: 0000000000042660 It would be good to see what's at ffffffff81d58fad. My guess would be that it's xsetbv. If it is then you probably want to make sure you are running hypervisor that has commit e8121c54 ("x86/xsave: enable support for new ISA extensions"). Looks like the first version that has it is 4.5 and you seem to be running 4.4.2. Copying Jan to see if there are plans to backport this (probably not since it's a new feature). -boris ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xen-devel] PROBLEM: kernel panic xsave_init 2015-10-19 16:25 ` [Xen-devel] " Boris Ostrovsky @ 2015-10-20 9:51 ` Jan Beulich 2015-10-20 12:11 ` John Doe 0 siblings, 1 reply; 9+ messages in thread From: Jan Beulich @ 2015-10-20 9:51 UTC (permalink / raw) To: John Doe, Boris Ostrovsky; +Cc: Ingo Molnar, x86, xen-devel, linux-kernel >>> On 19.10.15 at 18:25, <boris.ostrovsky@oracle.com> wrote: > On 10/19/2015 06:16 AM, John Doe wrote: >>>> [ 0.000000] general protection fault: 0000 [#1] SMP >>>> [ 0.000000] Modules linked in: >>>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted > 4.1.9-6.pvops.qubes.x86_64 #1 >>>> [ 0.000000] Hardware name: To Be Filled By O.E.M. To Be Filled By > O.E.M./Z170 Extreme4, BIOS P1.80 09/18/2015 >>>> [ 0.000000] task: ffffffff81c154c0 ti: ffffffff81c00000 task.ti: > ffffffff81c00000 >>>> [ 0.000000] RIP: e030:[<ffffffff81d58fad>] [<ffffffff81d58fad>] > xstate_enable_boot_cpu+0xde/0x288 >>>> [ 0.000000] RSP: e02b:ffffffff81c03de8 EFLAGS: 00010046 >>>> [ 0.000000] RAX: 000000000000001f RBX: 0000000000000008 RCX: > 0000000000000000 >>>> [ 0.000000] RDX: 0000000000000000 RSI: 000000000000001f RDI: > 0000000000042660 > > > It would be good to see what's at ffffffff81d58fad. My guess would be > that it's xsetbv. > > If it is then you probably want to make sure you are running hypervisor > that has commit e8121c54 ("x86/xsave: enable support for new ISA > extensions"). Looks like the first version that has it is 4.5 and you > seem to be running 4.4.2. > > Copying Jan to see if there are plans to backport this (probably not > since it's a new feature). Hmm, if there are features getting exposed that lead to crashes like this, then while we wouldn't normally backport enhancements, we may need to consider adding a one-off patch to hide respective features to that stable branch. But first we of course need to understand what is going on here. Jan ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xen-devel] PROBLEM: kernel panic xsave_init 2015-10-20 9:51 ` Jan Beulich @ 2015-10-20 12:11 ` John Doe 2015-10-20 13:22 ` Boris Ostrovsky 0 siblings, 1 reply; 9+ messages in thread From: John Doe @ 2015-10-20 12:11 UTC (permalink / raw) To: Jan Beulich, Boris Ostrovsky; +Cc: Ingo Molnar, x86, xen-devel, linux-kernel On 20/10/2015 11:51, Jan Beulich wrote: >>>> On 19.10.15 at 18:25, <boris.ostrovsky@oracle.com> wrote: >> On 10/19/2015 06:16 AM, John Doe wrote: >>>>> [ 0.000000] general protection fault: 0000 [#1] SMP >>>>> [ 0.000000] Modules linked in: >>>>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted >> 4.1.9-6.pvops.qubes.x86_64 #1 >>>>> [ 0.000000] Hardware name: To Be Filled By O.E.M. To Be Filled By >> O.E.M./Z170 Extreme4, BIOS P1.80 09/18/2015 >>>>> [ 0.000000] task: ffffffff81c154c0 ti: ffffffff81c00000 task.ti: >> ffffffff81c00000 >>>>> [ 0.000000] RIP: e030:[<ffffffff81d58fad>] [<ffffffff81d58fad>] >> xstate_enable_boot_cpu+0xde/0x288 >>>>> [ 0.000000] RSP: e02b:ffffffff81c03de8 EFLAGS: 00010046 >>>>> [ 0.000000] RAX: 000000000000001f RBX: 0000000000000008 RCX: >> 0000000000000000 >>>>> [ 0.000000] RDX: 0000000000000000 RSI: 000000000000001f RDI: >> 0000000000042660 >> >> >> It would be good to see what's at ffffffff81d58fad. My guess would be >> that it's xsetbv. >> >> If it is then you probably want to make sure you are running hypervisor >> that has commit e8121c54 ("x86/xsave: enable support for new ISA >> extensions"). Looks like the first version that has it is 4.5 and you >> seem to be running 4.4.2. >> >> Copying Jan to see if there are plans to backport this (probably not >> since it's a new feature). > > Hmm, if there are features getting exposed that lead to crashes like > this, then while we wouldn't normally backport enhancements, we > may need to consider adding a one-off patch to hide respective > features to that stable branch. But first we of course need to > understand what is going on here. > > Jan > I will try with 4.6.0 asap, unfortunately the 4.4.2 image i have is not built with debug enabled and i'm unable to run gdb at boot, i'm building a new one right now. If you need anything else please be very step-specific since i'm not very practical at this. Thank you, John. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xen-devel] PROBLEM: kernel panic xsave_init 2015-10-20 12:11 ` John Doe @ 2015-10-20 13:22 ` Boris Ostrovsky 2015-10-20 13:43 ` Jan Beulich 0 siblings, 1 reply; 9+ messages in thread From: Boris Ostrovsky @ 2015-10-20 13:22 UTC (permalink / raw) To: John Doe, Jan Beulich; +Cc: Ingo Molnar, x86, xen-devel, linux-kernel On 10/20/2015 08:11 AM, John Doe wrote: > On 20/10/2015 11:51, Jan Beulich wrote: >>>>> On 19.10.15 at 18:25, <boris.ostrovsky@oracle.com> wrote: >>> On 10/19/2015 06:16 AM, John Doe wrote: >>>>>> [ 0.000000] general protection fault: 0000 [#1] SMP >>>>>> [ 0.000000] Modules linked in: >>>>>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted >>> 4.1.9-6.pvops.qubes.x86_64 #1 >>>>>> [ 0.000000] Hardware name: To Be Filled By O.E.M. To Be Filled By >>> O.E.M./Z170 Extreme4, BIOS P1.80 09/18/2015 >>>>>> [ 0.000000] task: ffffffff81c154c0 ti: ffffffff81c00000 task.ti: >>> ffffffff81c00000 >>>>>> [ 0.000000] RIP: e030:[<ffffffff81d58fad>] [<ffffffff81d58fad>] >>> xstate_enable_boot_cpu+0xde/0x288 >>>>>> [ 0.000000] RSP: e02b:ffffffff81c03de8 EFLAGS: 00010046 >>>>>> [ 0.000000] RAX: 000000000000001f RBX: 0000000000000008 RCX: >>> 0000000000000000 >>>>>> [ 0.000000] RDX: 0000000000000000 RSI: 000000000000001f RDI: >>> 0000000000042660 >>> >>> >>> It would be good to see what's at ffffffff81d58fad. My guess would be >>> that it's xsetbv. >>> >>> If it is then you probably want to make sure you are running hypervisor >>> that has commit e8121c54 ("x86/xsave: enable support for new ISA >>> extensions"). Looks like the first version that has it is 4.5 and you >>> seem to be running 4.4.2. >>> >>> Copying Jan to see if there are plans to backport this (probably not >>> since it's a new feature). >> >> Hmm, if there are features getting exposed that lead to crashes like >> this, then while we wouldn't normally backport enhancements, we >> may need to consider adding a one-off patch to hide respective >> features to that stable branch. But first we of course need to >> understand what is going on here. The reason I think its this commit is that RAX, RDX and RCX look very much like arguments to xsetbv (which xstate_enable_boot_cpu() executes) and RAX value is 0x1f, which has two new bits that this commit defined. With this being a new processor (Skylake) it would be logical to have these bits provided by CPUID. >> >> Jan >> > > I will try with 4.6.0 asap, unfortunately the 4.4.2 image i have is not > built with debug enabled and i'm unable to run gdb at boot, i'm building > a new one right now. You should be able to use 'gdb /proc/kcore' and look at the instruction at (and around) 0xffffffff81d58fad. > If you need anything else please be very step-specific since i'm not > very practical at this. You can also try adding cpuid=['0xd,0:eax=00000000000000000000000000000111'] to your config file and see if it helps. -boris ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xen-devel] PROBLEM: kernel panic xsave_init 2015-10-20 13:22 ` Boris Ostrovsky @ 2015-10-20 13:43 ` Jan Beulich 2015-10-20 14:27 ` Boris Ostrovsky 0 siblings, 1 reply; 9+ messages in thread From: Jan Beulich @ 2015-10-20 13:43 UTC (permalink / raw) To: John Doe, Boris Ostrovsky; +Cc: Ingo Molnar, x86, xen-devel, linux-kernel >>> On 20.10.15 at 15:22, <boris.ostrovsky@oracle.com> wrote: > The reason I think its this commit is that RAX, RDX and RCX look very > much like arguments to xsetbv (which xstate_enable_boot_cpu() executes) > and RAX value is 0x1f, which has two new bits that this commit defined. That would be the two MPX related bits, yet us (luckily) white listing leaf 7 in pv_cpuid(), it is quite easy to validate that we don't expose this feature to PV(H) guests. Sadly the story is different for HVM guests (where the leaf handling uses black listing), but the register dump here clearly points to a PV guest (or Dom0). Jan ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xen-devel] PROBLEM: kernel panic xsave_init 2015-10-20 13:43 ` Jan Beulich @ 2015-10-20 14:27 ` Boris Ostrovsky 2015-10-20 14:41 ` Jan Beulich 2015-10-21 0:17 ` John Doe 0 siblings, 2 replies; 9+ messages in thread From: Boris Ostrovsky @ 2015-10-20 14:27 UTC (permalink / raw) To: Jan Beulich, John Doe; +Cc: Ingo Molnar, x86, xen-devel, linux-kernel On 10/20/2015 09:43 AM, Jan Beulich wrote: >>>> On 20.10.15 at 15:22, <boris.ostrovsky@oracle.com> wrote: >> The reason I think its this commit is that RAX, RDX and RCX look very >> much like arguments to xsetbv (which xstate_enable_boot_cpu() executes) >> and RAX value is 0x1f, which has two new bits that this commit defined. > That would be the two MPX related bits, yet us (luckily) white listing > leaf 7 in pv_cpuid(), it is quite easy to validate that we don't expose > this feature to PV(H) guests. Oh, so something like cpuid=['0x7:ebx=xxxxxxxxxxxxxxxxx0xxxxxxxxxxxxxx'] (bit 14 as zero) for John to try then. -boris > Sadly the story is different for HVM > guests (where the leaf handling uses black listing), but the register > dump here clearly points to a PV guest (or Dom0). > > Jan > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xen-devel] PROBLEM: kernel panic xsave_init 2015-10-20 14:27 ` Boris Ostrovsky @ 2015-10-20 14:41 ` Jan Beulich 2015-10-21 0:17 ` John Doe 1 sibling, 0 replies; 9+ messages in thread From: Jan Beulich @ 2015-10-20 14:41 UTC (permalink / raw) To: Boris Ostrovsky; +Cc: John Doe, Ingo Molnar, x86, xen-devel, linux-kernel >>> On 20.10.15 at 16:27, <boris.ostrovsky@oracle.com> wrote: > On 10/20/2015 09:43 AM, Jan Beulich wrote: >>>>> On 20.10.15 at 15:22, <boris.ostrovsky@oracle.com> wrote: >>> The reason I think its this commit is that RAX, RDX and RCX look very >>> much like arguments to xsetbv (which xstate_enable_boot_cpu() executes) >>> and RAX value is 0x1f, which has two new bits that this commit defined. >> That would be the two MPX related bits, yet us (luckily) white listing >> leaf 7 in pv_cpuid(), it is quite easy to validate that we don't expose >> this feature to PV(H) guests. > > Oh, so something like > > cpuid=['0x7:ebx=xxxxxxxxxxxxxxxxx0xxxxxxxxxxxxxx'] > > (bit 14 as zero) for John to try then. He might try it, but as per what I've said this shouldn't make a difference for PV(H) guests. Jan ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xen-devel] PROBLEM: kernel panic xsave_init 2015-10-20 14:27 ` Boris Ostrovsky 2015-10-20 14:41 ` Jan Beulich @ 2015-10-21 0:17 ` John Doe 1 sibling, 0 replies; 9+ messages in thread From: John Doe @ 2015-10-21 0:17 UTC (permalink / raw) To: Boris Ostrovsky, Jan Beulich; +Cc: Ingo Molnar, x86, xen-devel, linux-kernel On 20/10/2015 16:27, Boris Ostrovsky wrote: > On 10/20/2015 09:43 AM, Jan Beulich wrote: >>>>> On 20.10.15 at 15:22, <boris.ostrovsky@oracle.com> wrote: >>> The reason I think its this commit is that RAX, RDX and RCX look very >>> much like arguments to xsetbv (which xstate_enable_boot_cpu() executes) >>> and RAX value is 0x1f, which has two new bits that this commit defined. >> That would be the two MPX related bits, yet us (luckily) white listing >> leaf 7 in pv_cpuid(), it is quite easy to validate that we don't expose >> this feature to PV(H) guests. > > Oh, so something like > > cpuid=['0x7:ebx=xxxxxxxxxxxxxxxxx0xxxxxxxxxxxxxx'] > > (bit 14 as zero) for John to try then. > > > -boris > >> Sadly the story is different for HVM >> guests (where the leaf handling uses black listing), but the register >> dump here clearly points to a PV guest (or Dom0). >> >> Jan >> > Jan the dump is taken from serial connection to Dom0, it does crash during boot. I just tried with xen 4.6.0 and it booted properly without xsave=0. Running gdb against /proc/kcore, with a x/10x 0xffffffff81d58fad i just get null bytes, with both xen4.4.3 (xsave=0) and 4.6.0. Tomorrow i will send you the gdb output and i will try to run it during the boot process. J. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-10-21 0:17 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <562430E6.6010205@gmail.com>
[not found] ` <20151019075618.GA22488@gmail.com>
2015-10-19 10:16 ` PROBLEM: kernel panic xsave_init John Doe
2015-10-19 16:25 ` [Xen-devel] " Boris Ostrovsky
2015-10-20 9:51 ` Jan Beulich
2015-10-20 12:11 ` John Doe
2015-10-20 13:22 ` Boris Ostrovsky
2015-10-20 13:43 ` Jan Beulich
2015-10-20 14:27 ` Boris Ostrovsky
2015-10-20 14:41 ` Jan Beulich
2015-10-21 0:17 ` John Doe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).