* EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues @ 2015-01-26 16:27 Konrad Rzeszutek Wilk 2015-01-26 16:36 ` Andrew Cooper [not found] ` <54C680C90200007800059907@mail.emea.novell.com> 0 siblings, 2 replies; 27+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-01-26 16:27 UTC (permalink / raw) To: xen-devel, daniel.kiper, andrew.cooper3, jbeulich Hey Jan, Andrew, I am hoping you can help me in directing me where I ought to go next in debugging this. This is a Lenovo Thinkpad x230 with the latest BIOS and Xen 4.6 (todays 'staging' + my patches). Initially when I installed Xen the first time it would hang when loading the efi_vars module in Linux. Debugging a bit more and I found out that the issue is that we crash when calling GetNextVariableName (works fine with GetTime/SetTime, hand't tried GetVariable). I decided to implement in the hypervisor a little loop that would call GetNextVariableName and it works on my ASUS M5A87 board nicely. (attached at the bottom for comparison) However on this laptop it keeps on crashing. I've also added a bit of code to get the binary code from the GetNextVariableName to see if it looks legit - and it looks OK (obviously different from what the ASUS has implemented). Anyhow I am bit stuck: 1) It works with Linux, so what is it that Linux does that Xen does not? 2). I can't make sense of the stack trace. I am not entirely sure where it crashes in the firmware code - so I don't know what code to debug/print. I hadn't yet added debugging for the EFI L3/L4 pagetables to figure out the MFNs exactly. Thinking to sprinkle a bunch of printks - but perhaps you know what 1) is in comparison and I can also take that in account? Here is the USB debug (thanks for making that work - makes debugging so much easier!) trace of the crash along along with the decompilation of the assembler code. Full boot on Lenovo ThinkPad x230: Xen 4.6-unstable (XEN) Xen version 4.6-unstable (konrad@) (gcc (GCC) 4.9.2 20141101 (Red Hat 4.9.2-1)) debug=y Mon Jan 26 11:01:21 EST 2015 (XEN) Latest ChangeSet: Sun Jan 25 16:50:58 2015 -0500 git:16279eb-dirty (XEN) Bootloader: EFI (XEN) Command line: console=dbgp,vga dbgp=ehci1 loglvl=all iommu=verbose,debug vga=keep (XEN) Video information: (XEN) VGA is graphics mode 1366x768, 32 bpp (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 1 EDD information structures (XEN) EFI RAM map: (XEN) 0000000000000000 - 0000000000090000 (usable) (XEN) 0000000000090000 - 00000000000c0000 (reserved) (XEN) 0000000000100000 - 0000000020000000 (usable) (XEN) 0000000020000000 - 0000000020200000 (reserved) (XEN) 0000000020200000 - 0000000040004000 (usable) (XEN) 0000000040004000 - 0000000040005000 (reserved) (XEN) 0000000040005000 - 00000000cfdd0000 (usable) (XEN) 00000000cfdd0000 - 00000000cffd2000 (reserved) (XEN) 00000000cffd2000 - 00000000d6850000 (usable) (XEN) 00000000d6850000 - 00000000dae9f000 (reserved) (XEN) 00000000dae9f000 - 00000000daf9f000 (ACPI NVS) (XEN) 00000000daf9f000 - 00000000dafff000 (ACPI data) (XEN) 00000000dafff000 - 00000000db000000 (usable) (XEN) 00000000db000000 - 00000000dfa00000 (reserved) (XEN) 00000000f80f8000 - 00000000f80f9000 (reserved) (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) (XEN) 0000000100000000 - 000000021e600000 (usable) (XEN) 000000021e600000 - 000000021e800000 (reserved) (XEN) ACPI: RSDP DAFFE014, 0024 (r2 LENOVO) (XEN) ACPI: XSDT DAFFE170, 00C4 (r1 LENOVO TP-G2 2620 PTL 2) (XEN) ACPI: FACP DAFE5000, 010C (r5 LENOVO TP-G2 2620 PTL 2) (XEN) ACPI: DSDT DAFE7000, 11383 (r1 LENOVO TP-G2 2620 INTL 20061109) (XEN) ACPI: FACS DAF5A000, 0040 (XEN) ACPI: SLIC DAFFD000, 0176 (r1 LENOVO TP-G2 2620 PTL 1) (XEN) ACPI: TCPA DAFFC000, 0032 (r2 PTL LENOVO 6040000 LNVO 1) (XEN) ACPI: SSDT DAFFB000, 0408 (r1 LENOVO TP-SSDT2 200 INTL 20061109) (XEN) ACPI: SSDT DAFFA000, 0033 (r1 LENOVO TP-SSDT1 100 INTL 20061109) (XEN) ACPI: SSDT DAFF9000, 07A8 (r1 LENOVO SataAhci 1000 INTL 20061109) (XEN) ACPI: HPET DAFE3000, 0038 (r1 LENOVO TP-G2 2620 PTL 2) (XEN) ACPI: APIC DAFE2000, 0098 (r1 LENOVO TP-G2 2620 PTL 2) (XEN) ACPI: MCFG DAFE1000, 003C (r1 LENOVO TP-G2 2620 PTL 2) (XEN) ACPI: ECDT DAFE0000, 0052 (r1 LENOVO TP-G2 2620 PTL 2) (XEN) ACPI: FPDT DAFDF000, 0064 (r1 LENOVO TP-G2 2620 PTL 2) (XEN) ACPI: ASF! DAFE6000, 00A5 (r32 LENOVO TP-G2 2620 PTL 2) (XEN) ACPI: UEFI DAFDE000, 003E (r1 LENOVO TP-G2 2620 PTL 2) (XEN) ACPI: UEFI DAFDD000, 0042 (r1 PTL COMBUF 1 PTL 1) (XEN) ACPI: POAT DAFDC000, 0055 (r3 LENOVO TP-G2 2620 PTL 2) (XEN) ACPI: SSDT DAFDB000, 0C79 (r1 PmRef Cpu0Ist 3000 INTL 20061109) (XEN) ACPI: SSDT DAFDA000, 0A83 (r1 PmRef CpuPm 3000 INTL 20061109) (XEN) ACPI: DMAR DAFD9000, 00B8 (r1 INTEL SNB 1 INTL 1) (XEN) ACPI: UEFI DAFD8000, 02A6 (r1 LENOVO TP-G2 2620 PTL 2) (XEN) ACPI: DBG2 DAFD7000, 00E9 (r0 LENOVO TP-G2 2620 PTL 2) (XEN) System RAM: 8009MB (8202104kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-000000021e600000 (XEN) Domain heap initialised (XEN) vesafb: framebuffer at 0xe0000000, mapped to 0xffff82c000201000, using 6144k, total 65472k (XEN) vesafb: mode is 1366x768x32, linelength=5504, font 8x14 (XEN) vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0 (XEN) SMBIOS 2.7 present. (XEN) DMI 2.7 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x408 (XEN) ACPI: v5 SLEEP INFO: control[1:0], status[1:0] (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0] (XEN) ACPI: 32/64X FACS address mismatch in FADT - daf5a000/0000000000000000, using 32 (XEN) ACPI: wakeup_vec[daf5a00c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) Processor #0 7:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) (XEN) Processor #1 7:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) (XEN) Processor #2 7:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) (XEN) Processor #3 7:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) (XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) ACPI: IRQ9 used by override. (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000 (XEN) [VT-D]dmar.c:788: Host address width 36 (XEN) [VT-D]dmar.c:802: found ACPI_DMAR_DRHD: (XEN) [VT-D]dmar.c:472: dmaru->address = fed90000 (XEN) [VT-D]iommu.c:1136: drhd->address = fed90000 iommu->reg = ffff82c000802000 (XEN) [VT-D]iommu.c:1138: cap = c0000020e60262 ecap = f0101a (XEN) [VT-D]dmar.c:383: endpoint: 0000:00:02.0 (XEN) [VT-D]dmar.c:802: found ACPI_DMAR_DRHD: (XEN) [VT-D]dmar.c:472: dmaru->address = fed91000 (XEN) [VT-D]iommu.c:1136: drhd->address = fed91000 iommu->reg = ffff82c000804000 (XEN) [VT-D]iommu.c:1138: cap = c9008020660262 ecap = f0105a (XEN) [VT-D]dmar.c:397: IOAPIC: 0000:f0:1f.0 (XEN) [VT-D]dmar.c:361: MSI HPET: 0000:f0:0f.0 (XEN) [VT-D]dmar.c:486: flags: INCLUDE_ALL (XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR: (XEN) [VT-D]dmar.c:383: endpoint: 0000:00:1d.0 (XEN) [VT-D]dmar.c:383: endpoint: 0000:00:1a.0 (XEN) [VT-D]dmar.c:383: endpoint: 0000:00:14.0 (XEN) [VT-D]dmar.c:676: RMRR region: base_addr da2ba000 end_address da2d0fff (XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR: (XEN) [VT-D]dmar.c:383: endpoint: 0000:00:02.0 (XEN) [VT-D]dmar.c:676: RMRR region: base_addr db800000 end_address df9fffff (XEN) ERST table was not found (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 8 CPUs (4 hotplug CPUs) (XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X (XEN) Switched to APIC driver x2apic_cluster. (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2594.208 MHz processor. (XEN) EFI memory map: (XEN) 0000000000000-0000000000fff type=3 attr=000000000000000f (XEN) .. skipped! (XEN) 0000000001000-0000000056fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 0000000057000-0000000059fff type=2 attr=000000000000000f (XEN) .. skipped! (XEN) 000000005a000-000000005bfff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 000000005c000-0000000086fff type=3 attr=000000000000000f (XEN) .. skipped! (XEN) 0000000087000-0000000087fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 0000000088000-000000008ffff type=3 attr=000000000000000f (XEN) .. skipped! (XEN) 0000000090000-000000009ffff type=0 attr=000000000000000f (XEN) .. skipped! (XEN) 0000000100000-000000010ffff type=3 attr=000000000000000f (XEN) .. skipped! (XEN) 0000000110000-000001fffffff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 0000020000000-00000201fffff type=0 attr=000000000000000f (XEN) .. skipped! (XEN) 0000020200000-0000040003fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 0000040004000-0000040004fff type=0 attr=000000000000000f (XEN) .. skipped! (XEN) 0000040005000-00000cb521fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000cb522000-00000cd7b0fff type=2 attr=000000000000000f (XEN) .. skipped! (XEN) 00000cd7b1000-00000cd7d0fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000cd7d1000-00000cf82dfff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000cf82e000-00000cfdb9fff type=2 attr=000000000000000f (XEN) .. skipped! (XEN) 00000cfdba000-00000cfdcffff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000cfdd0000-00000cffd1fff type=0 attr=000000000000000f (XEN) .. skipped! (XEN) 00000cffd2000-00000d07a0fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d07a1000-00000d0c4ffff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d0c50000-00000d1e4ffff type=1 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d1e50000-00000d239cfff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d239d000-00000d2ba6fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d2ba7000-00000d2bc0fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d2bc1000-00000d304efff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d304f000-00000d3161fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d3162000-00000d334ffff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d3350000-00000d347cfff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d347d000-00000d4100fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d4101000-00000d4110fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d4111000-00000d44d2fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d44d3000-00000d44d7fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d44d8000-00000d44e6fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d44e7000-00000d44e7fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d44e8000-00000d5e4ffff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d5e50000-00000d5f86fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d5f87000-00000d684ffff type=3 attr=000000000000000f (XEN) .. skipped! (XEN) 00000d6850000-00000d6928fff type=5 attr=800000000000000f (XEN) 00000d6929000-00000d6a4ffff type=5 attr=800000000000000f (XEN) 00000d6a50000-00000d75f8fff type=6 attr=800000000000000f (XEN) 00000d75f9000-00000da49efff type=6 attr=800000000000000f (XEN) 00000da49f000-00000dabeffff type=0 attr=000000000000000f (XEN) .. skipped! (XEN) 00000dabf0000-00000dae9afff type=0 attr=000000000000000f (XEN) .. skipped! (XEN) 00000dae9b000-00000dae9bfff type=0 attr=000000000000000f (XEN) .. skipped! (XEN) 00000dae9c000-00000dae9efff type=0 attr=000000000000000f (XEN) .. skipped! (XEN) 00000dae9f000-00000daef4fff type=10 attr=000000000000000f (XEN) .. skipped! (XEN) 00000daef5000-00000daf9efff type=10 attr=000000000000000f (XEN) .. skipped! (XEN) 00000daf9f000-00000dafd6fff type=9 attr=000000000000000f (XEN) .. skipped! (XEN) 00000dafd7000-00000daffefff type=9 attr=000000000000000f (XEN) .. skipped! (XEN) 00000dafff000-00000daffffff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 0000100000000-000021e5fffff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000000a0000-00000000bffff type=0 attr=0000000000000000 (XEN) .. skipped! (XEN) 00000db000000-00000df9fffff type=0 attr=0000000000000000 (XEN) .. skipped! (XEN) 00000f80f8000-00000f80f8fff type=11 attr=8000000000000001 (XEN) 00000fed1c000-00000fed1ffff type=11 attr=8000000000000001 (XEN) 000021e600000-000021e7fffff type=0 attr=0000000000000000 (XEN) .. skipped! (XEN) Initing memory sharing. (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) mce_intel.c:735: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0 (XEN) Intel machine check reporting enabled (XEN) alt table ffff82d080449a10 -> ffff82d08044aa60 (XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f (XEN) PCI: Not using MCFG for segment 0000 bus 00-3f (XEN) Intel VT-d iommu 0 supported page sizes: 4kB. (XEN) Intel VT-d iommu 1 supported page sizes: 4kB. (XEN) Intel VT-d Snoop Control not enabled. (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) Intel VT-d Queued Invalidation enabled. (XEN) Intel VT-d Interrupt Remapping enabled. (XEN) Intel VT-d Shared EPT tables not enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Interrupt remapping enabled (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) ENABLING IO-APIC IRQs (XEN) -> Using old ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) TSC deadline timer enabled (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 32 KiB. (XEN) EFI v2.15, GetNextVariableName: d6994cd4, GetVariable: d6994b28 (XEN) Code: 48 89 5c 24 08 48 89 6c 24 10 48 89 74 24 18 57 41 54 41 55 48 83 ec 20 45 33 ed 48 85 c9 4d 8b e0 48 8b fa 48 8b e9 0f 84 09 01 00 00 48 85 d2 0f 84 00 01 00 00 4d 85 c0 0f 84 f7 00 00 00 48 8b 05 76 11 00 00 48 8d 15 af 11 00 00 48 8b c8 ff 50 20 80 3d a2 11 00 00 01 75 1b 48 8b 05 81 11 00 00 4d 8b c4 48 8b d7 48 8b cd ff 50 08 48 8b d8 e9 ba 00 00 00 48 8b cf e8 bd 0f 00 00 48 3d 00 01 00 00 0f 87 ab 00 00 00 44 38 2d c2 10 00 00 75 12 48 8b 05 d1 10 00 00 b9 1f 00 00 00 ff 50 18 4c 8b e8 48 8b 35 27 11 00 00 48 8b d7 c6 06 5a c6 46 01 6b 48 8b 4d 00 48 89 4e 18 48 8d 4e 20 e8 58 0f 00 00 48 8d 8e 20 02 00 00 41 b8 10 00 00 00 49 8b d4 e8 ff 0e 00 00 e8 3a fb ff ff 44 8a 1e 41 80 fb 5a 74 bb 48 8b 5e 08 48 8b 46 18 48 85 db 48 89 45 00 75 1f 48 8d 56 20 48 8b cf e8 18 0f 00 00 48 8d 96 20 02 00 00 44 8d 43 10 49 8b cc e8 c1 0e 00 00 80 3d 32 10 00 00 00 75 0d 48 8b 05 41 10 00 00 49 8b cd ff 50 20 48 8b c3 eb 0a 48 b8 02 00 00 00 00 00 00 80 48 8b 5c 24 40 48 8b 6c 24 48 48 8b 74 24 50 48 83 c4 20 41 5d 41 5c 5f c3 cc cc cc 48 8b c4 48 89 58 08 48 89 68 10 48 89 70 18 48 89 78 20 41 54 41 55 41 56 48 83 ec 30 45 33 e4 48 85 c9 49 8b f9 45 8b f0 4c 8b ea 48 8b d9 0f 84 2c 01 00 00 66 44 39 21 0f 84 22 01 00 00 48 85 d2 0f 84 19 01 00 00 48 8b 6c 24 70 48 85 ed 75 0f 4d 85 c9 74 0a 41 f6 c0 06 0f 85 00 01 00 00 48 8b 05 f8 0f 00 00 48 8d 15 31 10 00 00 48 8b c8 ff 50 20 80 3d 24 10 00 00 01 48 8b cb 75 20 48 8b 05 00 10 00 00 4c 8b cf 45 8b c6 49 8b d5 48 89 6c 24 20 ff 50 10 48 8b d8 e9 bb 00 00 00 e8 3a 0e 00 00 48 3d 00 01 00 00 0f 87 af 00 00 00 48 81 ff 00 40 01 00 76 0f 48 b8 09 00 00 00 00 00 00 80 e9 a1 00 00 00 44 38 25 27 0f 00 00 75 12 48 8b 05 36 0f 00 00 b9 1f 00 00 00 ff 50 18 4c 8b e0 48 8b 35 8c 0f 00 00 48 8b d3 c6 06 5a 48 8d 4e 18 c6 46 01 7c e8 c5 0d 00 00 48 8d 8e 18 02 00 00 41 b8 10 00 00 00 49 8b d5 e8 6c 0d 00 00 48 8d 8e 38 02 00 00 4c 8b c7 48 8b d5 44 89 b6 28 02 00 00 48 89 be 30 02 00 00 e8 4c 0d 00 00 e8 87 f9 ff ff 44 8a 1e 41 80 fb 5a 74 a3 80 3d af 0e 00 00 00 48 8b 5e 08 75 0d 48 8b 05 ba 0e 00 00 49 8b cc ff 50 20 48 8b c3 eb 0a 48 b8 02 00 00 00 00 00 00 80 48 8b 5c 24 50 48 8b 6c 24 58 48 8b 74 24 60 48 8b 7c 24 68 48 83 c4 30 41 5e 41 5d 41 5c c3 cc cc 48 89 5c 24 08 48 89 6c 24 10 48 89 74 24 18 57 41 54 41 55 48 83 ec 20 33 f6 48 85 d2 49 8b e9 4d 8b e0 4c 8b ea 8b f9 0f 84 c7 00 00 00 4d 85 c0 0f 84 be 00 00 00 4d 85 c9 0f 84 b5 00 00 00 85 c9 0f 84 ad 00 00 00 48 8b 05 85 0e 00 00 48 8d 15 be 0e 00 00 48 8b c8 ff 50 20 80 3d b1 0e 00 00 01 75 1a 48 8b 05 90 0e 00 00 4c 8b cd 4d 8b c4 49 8b d5 8b cf ff 50 18 48 8b f8 eb 71 40 38 35 e6 0d 00 00 75 12 48 8b 05 f5 0d 00 00 b9 1f 00 00 00 ff 50 18 48 8b f0 48 8b 1d 4b 0e 00 00 c6 03 5a c6 43 01 8d 89 7b 18 e8 84 f8 ff ff 44 8a 1b 41 80 fb 5a 74 e1 48 8b 7b 08 48 85 ff 78 18 48 8b 43 20 49 89 45 00 48 8b 43 28 49 89 04 24 48 8b 43 30 48 89 45 00 80 3d 8b 0d 00 00 00 75 0d 48 8b 05 9a 0d 00 00 48 8b ce ff 50 20 48 8b c7 eb 0a 48 b8 02 00 00 00 00 00 00 80 48 8b 5c 24 40 48 8b 6c 24 48 48 8b 74 24 50 48 83 c4 20 41 5d 41 5c 5f c3 (XEN) Delay of 3 seconds: ..3..2..1 (XEN) 1:Debugging connection not set up. (XEN) ----[ Xen-4.6-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e008:[<0000000000000007>] 0000000000000007 (XEN) RFLAGS: 0000000000010202 CONTEXT: hypervisor (XEN) rax: 00000000cfdba270 rbx: 0000000000000000 rcx: 000000000000001f (XEN) rdx: 00000000d6995ed0 rsi: 0000000000150670 rdi: ffff830214cfea00 (XEN) rbp: ffff82d080457e18 rsp: ffff82d080457d60 r8: ffff82d080457e08 (XEN) r9: 0000000000000001 r10: 0000000000000001 r11: 00000000db002700 (XEN) r12: ffff82d080457e08 r13: 0000000000000000 r14: ffff830216b27080 (XEN) r15: ffff82d080457e10 cr0: 0000000080050033 cr4: 00000000001506f0 (XEN) cr3: 0000000216b37000 cr2: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Xen stack trace from rsp=ffff82d080457d60: (XEN) 0000000068f00002 00000000d6994d77 00000000d109f000 0000000000000000 (XEN) ffff830214cfea00 ffff830216b27080 ffff830214cfea00 00000000d109f000 (XEN) 0000000000000000 ffff82d080236cb4 0000000000000000 ffff82d080457e50 (XEN) 0000000000150670 ffff82d080236c87 ffff82d080457e20 ffff82d080457e18 (XEN) ffff82d080457e08 0000000100000020 ffff830214cfe580 000000000000376f (XEN) 0000000000003fff 000000000000376f ffff82d080457e40 0000000000000400 (XEN) ffff830216b49fe0 0000000000000001 ffff830216b49fe0 0000000000000002 (XEN) 0000000000000000 0000000000000002 ffff82d080457f10 ffff82d080424aed (XEN) 0000000000000000 0000000000000000 ffff82d080445800 00000000012b0000 (XEN) 000000000021e600 0000000000000000 00000000012b0001 0000000000000014 (XEN) 0000000100000002 ffff8300d12497a0 ffff8300d12390ff ffff8300d1249800 (XEN) 0000000800000000 000000010000006e 0000000000000003 00000000000002f8 (XEN) 0000000000000000 00000000d1238640 00000000d0eff388 00000000fed20000 (XEN) 0000000000057000 0000000000002960 00000000d0793450 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<0000000000000007>] 0000000000000007 (XEN) [<ffff830216b49fe0>] ffff830216b49fe0 (XEN) (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) FATAL TRAP: vector = 6 (invalid opcode) (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... (XEN) Debugging connection not set up. Code: 48 89 5c 24 08 48 89 6c 24 10 48 89 74 24 18 57 41 54 41 55 48 83 ec 20 45 33 ed 48 85 c9 4d 8b e0 48 8b fa 48 8b e9 0f 84 09 01 00 00 48 85 d2 0f 84 00 01 00 00 4d 85 c0 0f 84 f7 00 00 00 48 8b 05 76 11 00 00 48 8d 15 af 11 00 00 48 8b c8 ff 50 20 80 3d a2 11 00 00 01 75 1b 48 8b 05 81 11 00 00 4d 8b c4 48 8b d7 48 8b cd ff 50 08 48 8b d8 e9 ba 00 00 00 48 8b cf e8 bd 0f 00 00 48 3d 00 01 00 00 0f 87 ab 00 00 00 44 38 2d c2 10 00 00 75 12 48 8b 05 d1 10 00 00 b9 1f 00 00 00 ff 50 18 4c 8b e8 48 8b 35 27 11 00 00 48 8b d7 c6 06 5a c6 46 01 6b 48 8b 4d 00 48 89 4e 18 48 8d 4e 20 e8 58 0f 00 00 48 8d 8e 20 02 00 00 41 b8 10 00 00 00 49 8b d4 e8 ff 0e 00 00 e8 3a fb ff ff 44 8a 1e 41 80 fb 5a 74 bb 48 8b 5e 08 48 8b 46 18 48 85 db 48 89 45 00 75 1f 48 8d 56 20 48 8b cf e8 18 0f 00 00 48 8d 96 20 02 00 00 44 8d 43 10 49 8b cc e8 c1 0e 00 00 80 3d 32 10 00 00 00 75 0d 48 8b 05 41 10 00 00 49 8b cd ff 50 20 48 8b c3 eb 0a 48 b8 02 00 00 00 00 00 00 80 48 8b 5c 24 40 48 8b 6c 24 48 48 8b 74 24 50 48 83 c4 20 41 5d 41 5c 5f c3 cc cc cc 48 8b c4 48 89 58 08 48 89 68 10 48 89 70 18 48 89 78 20 41 54 41 55 41 56 48 83 ec 30 45 33 e4 48 85 c9 49 8b f9 45 8b f0 4c 8b ea 48 8b d9 0f 84 2c 01 00 00 66 44 39 21 0f 84 22 01 00 00 48 85 d2 0f 84 19 01 00 00 48 8b 6c 24 70 48 85 ed 75 0f 4d 85 c9 74 0a 41 f6 c0 06 0f 85 00 01 00 00 48 8b 05 f8 0f 00 00 48 8d 15 31 10 00 00 48 8b c8 ff 50 20 80 3d 24 10 00 00 01 48 8b cb 75 20 48 8b 05 00 10 00 00 4c 8b cf 45 8b c6 49 8b d5 48 89 6c 24 20 ff 50 10 48 8b d8 e9 bb 00 00 00 e8 3a 0e 00 00 48 3d 00 01 00 00 0f 87 af 00 00 00 48 81 ff 00 40 01 00 76 0f 48 b8 09 00 00 00 00 00 00 80 e9 a1 00 00 00 44 38 25 27 0f 00 00 75 12 48 8b 05 36 0f 00 00 b9 1f 00 00 00 ff 50 18 4c 8b e0 48 8b 35 8c 0f 00 00 48 8b d3 c6 06 5a 48 8d 4e 18 c6 46 01 7c e8 c5 0d 00 00 48 8d 8e 18 02 00 00 41 b8 10 00 00 00 49 8b d5 e8 6c 0d 00 00 48 8d 8e 38 02 00 00 4c 8b c7 48 8b d5 44 89 b6 28 02 00 00 48 89 be 30 02 00 00 e8 4c 0d 00 00 e8 87 f9 ff ff 44 8a 1e 41 80 fb 5a 74 a3 80 3d af 0e 00 00 00 48 8b 5e 08 75 0d 48 8b 05 ba 0e 00 00 49 8b cc ff 50 20 48 8b c3 eb 0a 48 b8 02 00 00 00 00 00 00 80 48 8b 5c 24 50 48 8b 6c 24 58 48 8b 74 24 60 48 8b 7c 24 68 48 83 c4 30 41 5e 41 5d 41 5c c3 cc cc 48 89 5c 24 08 48 89 6c 24 10 48 89 74 24 18 57 41 54 41 55 48 83 ec 20 33 f6 48 85 d2 49 8b e9 4d 8b e0 4c 8b ea 8b f9 0f 84 c7 00 00 00 4d 85 c0 0f 84 be 00 00 00 4d 85 c9 0f 84 b5 00 00 00 85 c9 0f 84 ad 00 00 00 48 8b 05 85 0e 00 00 48 8d 15 be 0e 00 00 48 8b c8 ff 50 20 80 3d b1 0e 00 00 01 75 1a 48 8b 05 90 0e 00 00 4c 8b cd 4d 8b c4 49 8b d5 8b cf ff 50 18 48 8b f8 eb 71 40 38 35 e6 0d 00 00 75 12 48 8b 05 f5 0d 00 00 b9 1f 00 00 00 ff 50 18 48 8b f0 48 8b 1d 4b 0e 00 00 c6 03 5a c6 43 01 8d 89 7b 18 e8 84 f8 ff ff 44 8a 1b 41 80 fb 5a 74 e1 48 8b 7b 08 48 85 ff 78 18 48 8b 43 20 49 89 45 00 48 8b 43 28 49 89 04 24 48 8b 43 30 48 89 45 00 80 3d 8b 0d 00 00 00 75 0d 48 8b 05 9a 0d 00 00 48 8b ce ff 50 20 48 8b c7 eb 0a 48 b8 02 00 00 00 00 00 00 80 48 8b 5c 24 40 48 8b 6c 24 48 48 8b 74 24 50 48 83 c4 20 41 5d 41 5c 5f c3 Code starting with the faulting instruction =========================================== 0: 48 89 5c 24 08 mov %rbx,0x8(%rsp) 5: 48 89 6c 24 10 mov %rbp,0x10(%rsp) a: 48 89 74 24 18 mov %rsi,0x18(%rsp) f: 57 push %rdi 10: 41 54 push %r12 12: 41 55 push %r13 14: 48 83 ec 20 sub $0x20,%rsp 18: 45 33 ed xor %r13d,%r13d 1b: 48 85 c9 test %rcx,%rcx 1e: 4d 8b e0 mov %r8,%r12 21: 48 8b fa mov %rdx,%rdi 24: 48 8b e9 mov %rcx,%rbp 27: 0f 84 09 01 00 00 je 0x136 2d: 48 85 d2 test %rdx,%rdx 30: 0f 84 00 01 00 00 je 0x136 36: 4d 85 c0 test %r8,%r8 39: 0f 84 f7 00 00 00 je 0x136 3f: 48 8b 05 76 11 00 00 mov 0x1176(%rip),%rax # 0x11bc 46: 48 8d 15 af 11 00 00 lea 0x11af(%rip),%rdx # 0x11fc 4d: 48 8b c8 mov %rax,%rcx 50: ff 50 20 callq *0x20(%rax) 53: 80 3d a2 11 00 00 01 cmpb $0x1,0x11a2(%rip) # 0x11fc 5a: 75 1b jne 0x77 5c: 48 8b 05 81 11 00 00 mov 0x1181(%rip),%rax # 0x11e4 63: 4d 8b c4 mov %r12,%r8 66: 48 8b d7 mov %rdi,%rdx 69: 48 8b cd mov %rbp,%rcx 6c: ff 50 08 callq *0x8(%rax) 6f: 48 8b d8 mov %rax,%rbx 72: e9 ba 00 00 00 jmpq 0x131 77: 48 8b cf mov %rdi,%rcx 7a: e8 bd 0f 00 00 callq 0x103c 7f: 48 3d 00 01 00 00 cmp $0x100,%rax 85: 0f 87 ab 00 00 00 ja 0x136 8b: 44 38 2d c2 10 00 00 cmp %r13b,0x10c2(%rip) # 0x1154 92: 75 12 jne 0xa6 94: 48 8b 05 d1 10 00 00 mov 0x10d1(%rip),%rax # 0x116c 9b: b9 1f 00 00 00 mov $0x1f,%ecx a0: ff 50 18 callq *0x18(%rax) a3: 4c 8b e8 mov %rax,%r13 a6: 48 8b 35 27 11 00 00 mov 0x1127(%rip),%rsi # 0x11d4 ad: 48 8b d7 mov %rdi,%rdx b0: c6 06 5a movb $0x5a,(%rsi) b3: c6 46 01 6b movb $0x6b,0x1(%rsi) b7: 48 8b 4d 00 mov 0x0(%rbp),%rcx bb: 48 89 4e 18 mov %rcx,0x18(%rsi) bf: 48 8d 4e 20 lea 0x20(%rsi),%rcx c3: e8 58 0f 00 00 callq 0x1020 c8: 48 8d 8e 20 02 00 00 lea 0x220(%rsi),%rcx cf: 41 b8 10 00 00 00 mov $0x10,%r8d d5: 49 8b d4 mov %r12,%rdx d8: e8 ff 0e 00 00 callq 0xfdc dd: e8 3a fb ff ff callq 0xfffffffffffffc1c e2: 44 8a 1e mov (%rsi),%r11b e5: 41 80 fb 5a cmp $0x5a,%r11b e9: 74 bb je 0xa6 eb: 48 8b 5e 08 mov 0x8(%rsi),%rbx ef: 48 8b 46 18 mov 0x18(%rsi),%rax f3: 48 85 db test %rbx,%rbx f6: 48 89 45 00 mov %rax,0x0(%rbp) fa: 75 1f jne 0x11b fc: 48 8d 56 20 lea 0x20(%rsi),%rdx 100: 48 8b cf mov %rdi,%rcx 103: e8 18 0f 00 00 callq 0x1020 108: 48 8d 96 20 02 00 00 lea 0x220(%rsi),%rdx 10f: 44 8d 43 10 lea 0x10(%rbx),%r8d 113: 49 8b cc mov %r12,%rcx 116: e8 c1 0e 00 00 callq 0xfdc 11b: 80 3d 32 10 00 00 00 cmpb $0x0,0x1032(%rip) # 0x1154 122: 75 0d jne 0x131 124: 48 8b 05 41 10 00 00 mov 0x1041(%rip),%rax # 0x116c 12b: 49 8b cd mov %r13,%rcx 12e: ff 50 20 callq *0x20(%rax) 131: 48 8b c3 mov %rbx,%rax 134: eb 0a jmp 0x140 136: 48 b8 02 00 00 00 00 movabs $0x8000000000000002,%rax 13d: 00 00 80 140: 48 8b 5c 24 40 mov 0x40(%rsp),%rbx 145: 48 8b 6c 24 48 mov 0x48(%rsp),%rbp 14a: 48 8b 74 24 50 mov 0x50(%rsp),%rsi 14f: 48 83 c4 20 add $0x20,%rsp 153: 41 5d pop %r13 155: 41 5c pop %r12 157: 5f pop %rdi 158: c3 retq 159: cc int3 15a: cc int3 15b: cc int3 15c: 48 8b c4 mov %rsp,%rax 15f: 48 89 58 08 mov %rbx,0x8(%rax) 163: 48 89 68 10 mov %rbp,0x10(%rax) 167: 48 89 70 18 mov %rsi,0x18(%rax) 16b: 48 89 78 20 mov %rdi,0x20(%rax) 16f: 41 54 push %r12 171: 41 55 push %r13 173: 41 56 push %r14 175: 48 83 ec 30 sub $0x30,%rsp 179: 45 33 e4 xor %r12d,%r12d 17c: 48 85 c9 test %rcx,%rcx 17f: 49 8b f9 mov %r9,%rdi 182: 45 8b f0 mov %r8d,%r14d 185: 4c 8b ea mov %rdx,%r13 188: 48 8b d9 mov %rcx,%rbx 18b: 0f 84 2c 01 00 00 je 0x2bd 191: 66 44 39 21 cmp %r12w,(%rcx) 195: 0f 84 22 01 00 00 je 0x2bd 19b: 48 85 d2 test %rdx,%rdx 19e: 0f 84 19 01 00 00 je 0x2bd 1a4: 48 8b 6c 24 70 mov 0x70(%rsp),%rbp 1a9: 48 85 ed test %rbp,%rbp 1ac: 75 0f jne 0x1bd 1ae: 4d 85 c9 test %r9,%r9 1b1: 74 0a je 0x1bd 1b3: 41 f6 c0 06 test $0x6,%r8b 1b7: 0f 85 00 01 00 00 jne 0x2bd 1bd: 48 8b 05 f8 0f 00 00 mov 0xff8(%rip),%rax # 0x11bc 1c4: 48 8d 15 31 10 00 00 lea 0x1031(%rip),%rdx # 0x11fc 1cb: 48 8b c8 mov %rax,%rcx 1ce: ff 50 20 callq *0x20(%rax) 1d1: 80 3d 24 10 00 00 01 cmpb $0x1,0x1024(%rip) # 0x11fc 1d8: 48 8b cb mov %rbx,%rcx 1db: 75 20 jne 0x1fd 1dd: 48 8b 05 00 10 00 00 mov 0x1000(%rip),%rax # 0x11e4 1e4: 4c 8b cf mov %rdi,%r9 1e7: 45 8b c6 mov %r14d,%r8d 1ea: 49 8b d5 mov %r13,%rdx 1ed: 48 89 6c 24 20 mov %rbp,0x20(%rsp) 1f2: ff 50 10 callq *0x10(%rax) 1f5: 48 8b d8 mov %rax,%rbx 1f8: e9 bb 00 00 00 jmpq 0x2b8 1fd: e8 3a 0e 00 00 callq 0x103c 202: 48 3d 00 01 00 00 cmp $0x100,%rax 208: 0f 87 af 00 00 00 ja 0x2bd 20e: 48 81 ff 00 40 01 00 cmp $0x14000,%rdi 215: 76 0f jbe 0x226 217: 48 b8 09 00 00 00 00 movabs $0x8000000000000009,%rax 21e: 00 00 80 221: e9 a1 00 00 00 jmpq 0x2c7 226: 44 38 25 27 0f 00 00 cmp %r12b,0xf27(%rip) # 0x1154 22d: 75 12 jne 0x241 22f: 48 8b 05 36 0f 00 00 mov 0xf36(%rip),%rax # 0x116c 236: b9 1f 00 00 00 mov $0x1f,%ecx 23b: ff 50 18 callq *0x18(%rax) 23e: 4c 8b e0 mov %rax,%r12 241: 48 8b 35 8c 0f 00 00 mov 0xf8c(%rip),%rsi # 0x11d4 248: 48 8b d3 mov %rbx,%rdx 24b: c6 06 5a movb $0x5a,(%rsi) 24e: 48 8d 4e 18 lea 0x18(%rsi),%rcx 252: c6 46 01 7c movb $0x7c,0x1(%rsi) 256: e8 c5 0d 00 00 callq 0x1020 25b: 48 8d 8e 18 02 00 00 lea 0x218(%rsi),%rcx 262: 41 b8 10 00 00 00 mov $0x10,%r8d 268: 49 8b d5 mov %r13,%rdx 26b: e8 6c 0d 00 00 callq 0xfdc 270: 48 8d 8e 38 02 00 00 lea 0x238(%rsi),%rcx 277: 4c 8b c7 mov %rdi,%r8 27a: 48 8b d5 mov %rbp,%rdx 27d: 44 89 b6 28 02 00 00 mov %r14d,0x228(%rsi) 284: 48 89 be 30 02 00 00 mov %rdi,0x230(%rsi) 28b: e8 4c 0d 00 00 callq 0xfdc 290: e8 87 f9 ff ff callq 0xfffffffffffffc1c 295: 44 8a 1e mov (%rsi),%r11b 298: 41 80 fb 5a cmp $0x5a,%r11b 29c: 74 a3 je 0x241 29e: 80 3d af 0e 00 00 00 cmpb $0x0,0xeaf(%rip) # 0x1154 2a5: 48 8b 5e 08 mov 0x8(%rsi),%rbx 2a9: 75 0d jne 0x2b8 2ab: 48 8b 05 ba 0e 00 00 mov 0xeba(%rip),%rax # 0x116c 2b2: 49 8b cc mov %r12,%rcx 2b5: ff 50 20 callq *0x20(%rax) 2b8: 48 8b c3 mov %rbx,%rax 2bb: eb 0a jmp 0x2c7 2bd: 48 b8 02 00 00 00 00 movabs $0x8000000000000002,%rax 2c4: 00 00 80 2c7: 48 8b 5c 24 50 mov 0x50(%rsp),%rbx 2cc: 48 8b 6c 24 58 mov 0x58(%rsp),%rbp 2d1: 48 8b 74 24 60 mov 0x60(%rsp),%rsi 2d6: 48 8b 7c 24 68 mov 0x68(%rsp),%rdi 2db: 48 83 c4 30 add $0x30,%rsp 2df: 41 5e pop %r14 2e1: 41 5d pop %r13 2e3: 41 5c pop %r12 2e5: c3 retq 2e6: cc int3 2e7: cc int3 2e8: 48 89 5c 24 08 mov %rbx,0x8(%rsp) 2ed: 48 89 6c 24 10 mov %rbp,0x10(%rsp) 2f2: 48 89 74 24 18 mov %rsi,0x18(%rsp) 2f7: 57 push %rdi 2f8: 41 54 push %r12 2fa: 41 55 push %r13 2fc: 48 83 ec 20 sub $0x20,%rsp 300: 33 f6 xor %esi,%esi 302: 48 85 d2 test %rdx,%rdx 305: 49 8b e9 mov %r9,%rbp 308: 4d 8b e0 mov %r8,%r12 30b: 4c 8b ea mov %rdx,%r13 30e: 8b f9 mov %ecx,%edi 310: 0f 84 c7 00 00 00 je 0x3dd 316: 4d 85 c0 test %r8,%r8 319: 0f 84 be 00 00 00 je 0x3dd 31f: 4d 85 c9 test %r9,%r9 322: 0f 84 b5 00 00 00 je 0x3dd 328: 85 c9 test %ecx,%ecx 32a: 0f 84 ad 00 00 00 je 0x3dd 330: 48 8b 05 85 0e 00 00 mov 0xe85(%rip),%rax # 0x11bc 337: 48 8d 15 be 0e 00 00 lea 0xebe(%rip),%rdx # 0x11fc 33e: 48 8b c8 mov %rax,%rcx 341: ff 50 20 callq *0x20(%rax) 344: 80 3d b1 0e 00 00 01 cmpb $0x1,0xeb1(%rip) # 0x11fc 34b: 75 1a jne 0x367 34d: 48 8b 05 90 0e 00 00 mov 0xe90(%rip),%rax # 0x11e4 354: 4c 8b cd mov %rbp,%r9 357: 4d 8b c4 mov %r12,%r8 35a: 49 8b d5 mov %r13,%rdx 35d: 8b cf mov %edi,%ecx 35f: ff 50 18 callq *0x18(%rax) 362: 48 8b f8 mov %rax,%rdi 365: eb 71 jmp 0x3d8 367: 40 38 35 e6 0d 00 00 cmp %sil,0xde6(%rip) # 0x1154 36e: 75 12 jne 0x382 370: 48 8b 05 f5 0d 00 00 mov 0xdf5(%rip),%rax # 0x116c 377: b9 1f 00 00 00 mov $0x1f,%ecx 37c: ff 50 18 callq *0x18(%rax) 37f: 48 8b f0 mov %rax,%rsi 382: 48 8b 1d 4b 0e 00 00 mov 0xe4b(%rip),%rbx # 0x11d4 389: c6 03 5a movb $0x5a,(%rbx) 38c: c6 43 01 8d movb $0x8d,0x1(%rbx) 390: 89 7b 18 mov %edi,0x18(%rbx) 393: e8 84 f8 ff ff callq 0xfffffffffffffc1c 398: 44 8a 1b mov (%rbx),%r11b 39b: 41 80 fb 5a cmp $0x5a,%r11b 39f: 74 e1 je 0x382 3a1: 48 8b 7b 08 mov 0x8(%rbx),%rdi 3a5: 48 85 ff test %rdi,%rdi 3a8: 78 18 js 0x3c2 3aa: 48 8b 43 20 mov 0x20(%rbx),%rax 3ae: 49 89 45 00 mov %rax,0x0(%r13) 3b2: 48 8b 43 28 mov 0x28(%rbx),%rax 3b6: 49 89 04 24 mov %rax,(%r12) 3ba: 48 8b 43 30 mov 0x30(%rbx),%rax 3be: 48 89 45 00 mov %rax,0x0(%rbp) 3c2: 80 3d 8b 0d 00 00 00 cmpb $0x0,0xd8b(%rip) # 0x1154 3c9: 75 0d jne 0x3d8 3cb: 48 8b 05 9a 0d 00 00 mov 0xd9a(%rip),%rax # 0x116c 3d2: 48 8b ce mov %rsi,%rcx 3d5: ff 50 20 callq *0x20(%rax) 3d8: 48 8b c7 mov %rdi,%rax 3db: eb 0a jmp 0x3e7 3dd: 48 b8 02 00 00 00 00 movabs $0x8000000000000002,%rax 3e4: 00 00 80 3e7: 48 8b 5c 24 40 mov 0x40(%rsp),%rbx 3ec: 48 8b 6c 24 48 mov 0x48(%rsp),%rbp 3f1: 48 8b 74 24 50 mov 0x50(%rsp),%rsi 3f6: 48 83 c4 20 add $0x20,%rsp 3fa: 41 5d pop %r13 3fc: 41 5c pop %r12 3fe: 5f pop %rdi 3ff: c3 retq >From 16279eb85543f14b2d1e7041616c4f36c183506c Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Sun, 25 Jan 2015 16:50:58 -0500 Subject: [PATCH] efi debug Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- xen/arch/x86/efi/stub.c | 1 + xen/arch/x86/setup.c | 7 +++ xen/common/efi/boot.c | 9 ++-- xen/common/efi/runtime.c | 127 ++++++++++++++++++++++++++++++++++++++++++++++- xen/include/xen/efi.h | 1 + 5 files changed, 141 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c index b8f49f8..cefd18d 100644 --- a/xen/arch/x86/efi/stub.c +++ b/xen/arch/x86/efi/stub.c @@ -21,6 +21,7 @@ unsigned long efi_get_time(void) return 0; } +long efi_debug(void) { return -ENOSYS; } void efi_halt_system(void) { } void efi_reset_system(bool_t warm) { } diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 39f2a4d..3517095 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1316,6 +1316,13 @@ void __init noreturn __start_xen(unsigned long mbi_p) console_init_postirq(); + if ( efi_enabled ) + { + long ret = efi_debug(); + if ( ret ) + printk("efi_debug return code: %lx\n", ret); + } + system_state = SYS_STATE_smp_boot; do_presmp_initcalls(); diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index ac6881e..c11b572 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -1089,6 +1089,9 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) static bool_t __initdata efi_rs_enable = 1; boolean_param("efi-rs", efi_rs_enable); +static bool_t __initdata efi_pg = 1; +boolean_param("efi-pg", efi_pg); + #ifndef USE_SET_VIRTUAL_ADDRESS_MAP static __init void copy_mapping(unsigned long mfn, unsigned long end, bool_t (*is_valid)(unsigned long smfn, @@ -1163,8 +1166,10 @@ void __init efi_init_memory(void) desc->Type, desc->Attribute); if ( !efi_rs_enable || !(desc->Attribute & EFI_MEMORY_RUNTIME) ) + { + printk(XENLOG_INFO " .. skipped!\n"); continue; - + } desc->VirtualStart = INVALID_VIRTUAL_ADDRESS; smfn = PFN_DOWN(desc->PhysicalStart); @@ -1225,13 +1230,11 @@ void __init efi_init_memory(void) smfn, emfn - 1); } } - if ( !efi_rs_enable ) { efi_fw_vendor = NULL; return; } - #ifdef USE_SET_VIRTUAL_ADDRESS_MAP efi_rs->SetVirtualAddressMap(efi_memmap_size, efi_mdesc_size, mdesc_ver, efi_memmap); diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c index c840e08..0750436 100644 --- a/xen/common/efi/runtime.c +++ b/xen/common/efi/runtime.c @@ -5,7 +5,8 @@ #include <xen/guest_access.h> #include <xen/irq.h> #include <xen/time.h> - +#include <xen/delay.h> +#include <xen/softirq.h> DEFINE_XEN_GUEST_HANDLE(CHAR16); #ifndef COMPAT @@ -128,6 +129,117 @@ unsigned long efi_get_time(void) time.Hour, time.Minute, time.Second); } +static void _delay(void) +{ + unsigned int i; + + printk("Delay of 3 seconds: "); + for (i = 0; i < 3; i++) + { + unsigned int j; + printk("..%d", (3 - i)); + for (j = 0; j < 100; j++) + { + process_pending_softirqs(); + mdelay(10); + } + } + printk("\n"); +} + +long efi_debug(void) +{ + unsigned long cr3 = efi_rs_enter(); + union { + CHAR16 *str; + unsigned char *raw; + } name; + char *p; + UINTN size = 1024; + struct xenpf_efi_guid guid; + EFI_STATUS status; + unsigned int i, idx; + unsigned int rev; + unsigned long getnext, get; + char *code; + + if ( !cr3 ) + return -EOPNOTSUPP; + efi_rs_leave(cr3); + + code = xzalloc_bytes(size); + if ( !code ) + return -ENOMEM; + + name.raw = xzalloc_bytes(size); + if ( !name.raw ) + { + xfree(code); + return -ENOMEM; + } + p = xzalloc_bytes(size); + if ( !p ) + { + xfree(code); + xfree(name.raw); + return -ENOMEM; + } + + printk("EFI v"); + cr3 = efi_rs_enter(); + rev = efi_rs->Hdr.Revision; + efi_rs_leave(cr3); + printk("%d.%d", rev >> 16, rev & 0xF); + + cr3 = efi_rs_enter(); + getnext = (unsigned long)efi_rs->GetNextVariableName; + memcpy(code, efi_rs->GetNextVariableName, 1024); + get = (unsigned long)efi_rs->GetVariable; + efi_rs_leave(cr3); + + printk(", GetNextVariableName: %lx, GetVariable: %lx\n", getnext, get); + printk(" Code: "); + for ( i = 0; i < 1024;i++) + printk(" %02x", (unsigned short)code[i] & 0xFF); + printk("\n"); + + _delay(); + + idx = 1; + do { + printk("%4d:", idx++); + + cr3 = efi_rs_enter(); + if ( !cr3 ) + break; + size = 1024; + status = efi_rs->GetNextVariableName(&size, name.str, (void *)&guid); + efi_rs_leave(cr3); + + if ( !EFI_ERROR(status) ) + { + unsigned int j; + + printk("%04x-%02x-%02x-", guid.data1, guid.data2, guid.data3); + for ( i = 0; i < 8; i++) + printk("-%02x", guid.data4[i]); + + for ( i = 0, j = 0; i < size && j < size / sizeof(CHAR16); i++, j++) + p[j] = name.str[i] & 0xFF; + + p[j] = '\0'; + printk(": %s [%lx]\n", p, status); + } else + printk("EFI_ERROR: %lx\n", status); + } while ( !EFI_ERROR(status) ); + + xfree(p); + xfree(name.raw); + xfree(code); + if ( EFI_ERROR(EFI_NOT_FOUND) ) + return 0; + return status; +} void efi_halt_system(void) { EFI_STATUS status; @@ -163,6 +275,7 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info) { unsigned int i, n; + printk("%s: %x\n", __func__, idx); switch ( idx ) { case XEN_FW_EFI_VERSION: @@ -506,15 +619,27 @@ int efi_runtime_call(struct xenpf_efi_runtime_call *op) xfree(name.raw); return -EFAULT; } + printk(XENLOG_WARNING "EFI %s:%d allocated: %u bytes\n", __func__, __LINE__, (unsigned int)size); cr3 = efi_rs_enter(); if ( cr3 ) { + struct xenpf_efi_guid *_guid = &op->u.get_next_variable_name.vendor_guid; + status = efi_rs->GetNextVariableName( &size, name.str, cast_guid(&op->u.get_next_variable_name.vendor_guid)); efi_rs_leave(cr3); + printk(XENLOG_WARNING "EFI %s:%d status: %#lx, size: %u, [%04x-%02x-%02x-", + __func__, __LINE__, status, (unsigned int)size, + _guid->data1, _guid->data2, _guid->data3); + { + int i; + for (i = 0; i < 8; i++) + printk(XENLOG_WARNING "-%x-", _guid->data4[i]); + } + printk(XENLOG_WARNING "\n"); if ( !EFI_ERROR(status) && copy_to_guest(op->u.get_next_variable_name.name, name.raw, size) ) diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h index 5e02724..4e9ffbf 100644 --- a/xen/include/xen/efi.h +++ b/xen/include/xen/efi.h @@ -30,6 +30,7 @@ struct compat_pf_efi_runtime_call; void efi_init_memory(void); paddr_t efi_rs_page_table(void); unsigned long efi_get_time(void); +long efi_debug(void); void efi_halt_system(void); void efi_reset_system(bool_t warm); #ifndef COMPAT -- 2.1.0 On ASUS: Xen 4.6-unstable (XEN) Xen version 4.6-unstable (konrad@dumpdata.com) (gcc (GCC) 4.9.2 20141101 (Red Hat 4.9.2-1)) debug=y Mon Jan 26 10:16:42 EST 2015 (XEN) Latest ChangeSet: Sun Jan 25 16:50:58 2015 -0500 git:16279eb (XEN) Bootloader: EFI (XEN) Command line: console=vga,com1 com1=115200,8n1 loglvl=all noreboot guest_loglvl=all iommu=verbose,no-intremap,debug dom0_mem=max:2G (XEN) Video information: (XEN) VGA is graphics mode 1280x1024, 32 bpp (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 2 EDD information structures (XEN) EFI RAM map: (XEN) 0000000000000000 - 00000000000a0000 (usable) (XEN) 0000000000100000 - 00000000ba86d000 (usable) (XEN) 00000000ba86d000 - 00000000ba9f1000 (reserved) (XEN) 00000000ba9f1000 - 00000000baa01000 (ACPI data) (XEN) 00000000baa01000 - 00000000bb811000 (ACPI NVS) (XEN) 00000000bb811000 - 00000000bca35000 (reserved) (XEN) 00000000bca35000 - 00000000bca36000 (usable) (XEN) 00000000bca36000 - 00000000bcc3c000 (ACPI NVS) (XEN) 00000000bcc3c000 - 00000000bd083000 (usable) (XEN) 00000000bd083000 - 00000000bd7f4000 (reserved) (XEN) 00000000bd7f4000 - 00000000bd800000 (usable) (XEN) 00000000fec00000 - 00000000fec01000 (reserved) (XEN) 00000000fec10000 - 00000000fec11000 (reserved) (XEN) 00000000fec20000 - 00000000fec21000 (reserved) (XEN) 00000000fed00000 - 00000000fed01000 (reserved) (XEN) 00000000fed61000 - 00000000fed71000 (reserved) (XEN) 00000000fed80000 - 00000000fed90000 (reserved) (XEN) 00000000fef00000 - 0000000100000000 (reserved) (XEN) 0000000100001000 - 0000000240000000 (usable) (XEN) ACPI: RSDP BA9F8000, 0024 (r2 ALASKA) (XEN) ACPI: XSDT BA9F8070, 005C (r1 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: FACP BA9FEEB8, 010C (r5 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI Warning (tbfadt-0464): Optional field "Pm2ControlBlock" has zero address or length: 0000000000000000/1 [20070126] (XEN) ACPI: DSDT BA9F8168, 6D50 (r2 ALASKA A M I 0 INTL 20051117) (XEN) ACPI: FACS BB80BF80, 0040 (XEN) ACPI: APIC BA9FEFC8, 009E (r3 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: FPDT BA9FF068, 0044 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: MCFG BA9FF0B0, 003C (r1 ALASKA A M I 1072009 MSFT 10013) (XEN) ACPI: HPET BA9FF0F0, 0038 (r1 ALASKA A M I 1072009 AMI 5) (XEN) ACPI: IVRS BAA00898, 00C0 (r1 AMD RD890S 202031 AMD 0) (XEN) ACPI: SSDT BA9FF180, 1714 (r1 AMD POWERNOW 1 AMD 1) (XEN) System RAM: 8108MB (8302976kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-0000000240000000 (XEN) Domain heap initialised (XEN) vesafb: framebuffer at 0xfb000000, mapped to 0xffff82c000201000, using 5120k, total 5120k (XEN) vesafb: mode is 1280x1024x32, linelength=5120, font 8x16 (XEN) vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0 (XEN) SMBIOS 2.7 present. (XEN) DMI 2.7 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0] (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:804,1:0], pm1x_evt[1:800,1:0] (XEN) ACPI: 32/64X FACS address mismatch in FADT - bb80bf80/0000000000000000, using 32 (XEN) ACPI: wakeup_vec[bb80bf8c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x10] enabled) (XEN) Processor #16 5:2 APIC version 16 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x11] enabled) (XEN) Processor #17 5:2 APIC version 16 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x12] enabled) (XEN) Processor #18 5:2 APIC version 16 (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x13] enabled) (XEN) Processor #19 5:2 APIC version 16 (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled) (XEN) Processor #20 5:2 APIC version 16 (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x15] enabled) (XEN) Processor #21 5:2 APIC version 16 (XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x16] enabled) (XEN) Processor #22 5:2 APIC version 16 (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x17] enabled) (XEN) Processor #23 5:2 APIC version 16 (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) (XEN) ACPI: IOAPIC (id[0x09] address[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 9, version 33, address 0xfec00000, GSI 0-23 (XEN) ACPI: IOAPIC (id[0x0a] address[0xfec20000] gsi_base[24]) (XEN) IOAPIC[1]: apic_id 10, version 33, address 0xfec20000, GSI 24-55 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) ACPI: IRQ9 used by override. (XEN) Enabling APIC mode: Flat. Using 2 I/O APICs (XEN) ACPI: HPET id: 0x43538210 base: 0xfed00000 (XEN) ERST table was not found (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 8 CPUs (0 hotplug CPUs) (XEN) IRQ limits: 56 GSI, 1496 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3511.848 MHz processor. (XEN) EFI memory map: (XEN) 0000000000000-0000000007fff type=3 attr=000000000000000f (XEN) .. skipped! (XEN) 0000000008000-000000005bfff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 000000005c000-000000005efff type=2 attr=000000000000000f (XEN) .. skipped! (XEN) 000000005f000-000000005ffff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 0000000060000-000000009ffff type=3 attr=000000000000000f (XEN) .. skipped! (XEN) 0000000100000-0000000ffffff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 0000001000000-00000010fffff type=2 attr=000000000000000f (XEN) .. skipped! (XEN) 0000001100000-00000a3402fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000a3403000-00000a4c21fff type=2 attr=000000000000000f (XEN) .. skipped! (XEN) 00000a4c22000-00000a4c23fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000a4c24000-00000a5e23fff type=1 attr=000000000000000f (XEN) .. skipped! (XEN) 00000a5e24000-00000ad115fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad116000-00000ad66efff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad66f000-00000ad68bfff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad68c000-00000ad6affff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad6b0000-00000ad6b7fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad6b8000-00000ad6dafff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad6db000-00000ad6e3fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad6e4000-00000ad707fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad708000-00000ad713fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad714000-00000ad749fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad74a000-00000ad75dfff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad75e000-00000ad77cfff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad77d000-00000ad78cfff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad78d000-00000ad7b4fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad7b5000-00000ad7c8fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad7c9000-00000ad7fcfff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad7fd000-00000ad7fdfff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad7fe000-00000ad8a7fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad8a8000-00000ad8affff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad8b0000-00000ad8d0fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad8d1000-00000ad8d9fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad8da000-00000ad900fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad901000-00000ad90cfff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad90d000-00000ad941fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad942000-00000ad955fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad956000-00000ad974fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad975000-00000ad984fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad985000-00000ad9affff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad9b0000-00000ad9c3fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad9c4000-00000ad9f4fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ad9f5000-00000ada09fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ada0a000-00000ada5efff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ada5f000-00000ada6ffff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ada70000-00000adaa0fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000adaa1000-00000adaa8fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000adaa9000-00000adacafff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000adacb000-00000adad3fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000adad4000-00000adaf9fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000adafa000-00000adb05fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000adb06000-00000adbf4fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000adbf5000-00000adbf5fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000adbf6000-00000adc9bfff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000adc9c000-00000adca3fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000adca4000-00000adcc5fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000adcc6000-00000adccefff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000adccf000-00000ade4bfff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ade4c000-00000ade54fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ade55000-00000ade95fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ade96000-00000ade9dfff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ade9e000-00000adec0fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000adec1000-00000adec1fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000adec2000-00000ae295fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae296000-00000ae296fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae297000-00000ae3c4fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae3c5000-00000ae3c5fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae3c6000-00000ae403fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae404000-00000ae407fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae408000-00000ae5a3fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae5a4000-00000ae5a6fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae5a7000-00000ae5dbfff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae5dc000-00000ae5ddfff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae5de000-00000ae622fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae623000-00000ae624fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae625000-00000ae691fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae692000-00000ae697fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae698000-00000ae6e0fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae6e1000-00000ae6e2fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae6e3000-00000ae70bfff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae70c000-00000ae70cfff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae70d000-00000ae764fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae765000-00000ae766fff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ae767000-00000aebeafff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000aebeb000-00000aeeedfff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000aeeee000-00000aef99fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000aef9a000-00000aef9afff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000aef9b000-00000b9c41fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000b9c42000-00000ba1bdfff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ba1be000-00000ba86cfff type=3 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ba86d000-00000ba8b9fff type=0 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ba8ba000-00000ba9f0fff type=0 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ba9f1000-00000ba9f7fff type=9 attr=000000000000000f (XEN) .. skipped! (XEN) 00000ba9f8000-00000baa00fff type=9 attr=000000000000000f (XEN) .. skipped! (XEN) 00000baa01000-00000baee0fff type=10 attr=000000000000000f (XEN) .. skipped! (XEN) 00000baee1000-00000bb810fff type=10 attr=000000000000000f (XEN) .. skipped! (XEN) 00000bb811000-00000bc301fff type=6 attr=800000000000000f (XEN) 00000bc302000-00000bc991fff type=6 attr=800000000000000f (XEN) 00000bc992000-00000bc9b1fff type=5 attr=800000000000000f (XEN) 00000bc9b2000-00000bca34fff type=5 attr=800000000000000f (XEN) 00000bca35000-00000bca35fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000bca36000-00000bcc3bfff type=10 attr=000000000000000f (XEN) .. skipped! (XEN) 00000bcc3c000-00000bcd8afff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000bcd8b000-00000bd02afff type=3 attr=000000000000000f (XEN) .. skipped! (XEN) 00000bd02b000-00000bd02cfff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000bd02d000-00000bd030fff type=3 attr=000000000000000f (XEN) .. skipped! (XEN) 00000bd031000-00000bd034fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000bd035000-00000bd036fff type=3 attr=000000000000000f (XEN) .. skipped! (XEN) 00000bd037000-00000bd03afff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000bd03b000-00000bd03cfff type=3 attr=000000000000000f (XEN) .. skipped! (XEN) 00000bd03d000-00000bd065fff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000bd066000-00000bd082fff type=3 attr=000000000000000f (XEN) .. skipped! (XEN) 00000bd083000-00000bd7f3fff type=6 attr=800000000000000f (XEN) 00000bd7f4000-00000bd7fffff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 0000100001000-000023fffffff type=7 attr=000000000000000f (XEN) .. skipped! (XEN) 00000fec00000-00000fec00fff type=11 attr=8000000000000001 (XEN) 00000fec10000-00000fec10fff type=11 attr=8000000000000001 (XEN) 00000fec20000-00000fec20fff type=11 attr=8000000000000001 (XEN) 00000fed00000-00000fed00fff type=11 attr=8000000000000001 (XEN) 00000fed61000-00000fed70fff type=11 attr=8000000000000001 (XEN) 00000fed80000-00000fed8ffff type=11 attr=8000000000000001 (XEN) 00000fef00000-00000ffffffff type=11 attr=8000000000000001 (XEN) Initing memory sharing. (XEN) xstate_init: using cntxt_size: 0x3c0 and states: 0x4000000000000007 (XEN) AMD Fam15h machine check reporting enabled (XEN) alt table ffff82d080449910 -> ffff82d08044a960 (XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff (XEN) PCI: Not using MCFG for segment 0000 bus 00-ff (XEN) AMD-Vi: Found MSI capability block at 0x54 (XEN) AMD-Vi: ACPI Table: (XEN) AMD-Vi: Signature IVRS (XEN) AMD-Vi: Length 0xc0 (XEN) AMD-Vi: Revision 0x1 (XEN) AMD-Vi: CheckSum 0xe (XEN) AMD-Vi: OEM_Id AMD (XEN) AMD-Vi: OEM_Table_Id RD890S (XEN) AMD-Vi: OEM_Revision 0x202031 (XEN) AMD-Vi: Creator_Id AMD (XEN) AMD-Vi: Creator_Revision 0 (XEN) AMD-Vi: IVRS Block: type 0x10 flags 0x3e len 0x90 id 0x2 (XEN) AMD-Vi: IVHD Device Entry: type 0x3 id 0 flags 0 (XEN) AMD-Vi: Dev_Id Range: 0 -> 0x2 (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0x10 flags 0 (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0x100 flags 0 (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0x20 flags 0 (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0x200 flags 0 (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0x38 flags 0 (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0x300 flags 0 (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0x88 flags 0 (XEN) AMD-Vi: IVHD Device Entry: type 0x3 id 0x90 flags 0 (XEN) AMD-Vi: Dev_Id Range: 0x90 -> 0x92 (XEN) AMD-Vi: IVHD Device Entry: type 0x3 id 0x98 flags 0 (XEN) AMD-Vi: Dev_Id Range: 0x98 -> 0x9a (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0xa0 flags 0xd7 (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0xa2 flags 0 (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0xa3 flags 0 (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0xa4 flags 0 (XEN) AMD-Vi: IVHD Device Entry: type 0 id 0 flags 0 (XEN) AMD-Vi: IVHD Device Entry: type 0x43 id 0x400 flags 0 (XEN) AMD-Vi: Dev_Id Range: 0x400 -> 0x4ff alias 0xa4 (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0xa5 flags 0 (XEN) AMD-Vi: IVHD Device Entry: type 0x3 id 0xb0 flags 0 (XEN) AMD-Vi: Dev_Id Range: 0xb0 -> 0xb2 (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7 (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x1 handle 0x9 (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7 (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0 (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0 (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0xa (XEN) AMD-Vi: Disabled HAP memory map sharing with IOMMU (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Interrupt remapping disabled (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 64 KiB. (XEN) EFI v2.10, GetNextVariableName: bca29598, GetVariable: bca29518 (XEN) Code: 48 89 5c 24 08 48 89 74 24 10 57 48 83 ec 20 48 8b f1 48 8b 0d 87 90 00 00 49 8b d8 80 39 00 48 8b fa 74 0c 48 b8 0f 00 00 00 00 00 00 80 eb 25 e8 cb e6 ff ff 4c 8b c3 48 8b d7 48 8b ce e8 51 f8 ff ff 48 8b 0d 56 90 00 00 48 8b d8 e8 02 e7 ff ff 48 8b c3 48 8b 5c 24 30 48 8b 74 24 38 48 83 c4 20 5f c3 cc cc cc 48 89 5c 24 08 48 89 6c 24 10 48 89 74 24 18 57 48 83 ec 30 48 8b e9 48 8b 0d 1a 90 00 00 49 8b d9 80 39 00 41 8b f8 48 8b f2 74 0c 48 b8 0f 00 00 00 00 00 00 80 eb 32 e8 5b e6 ff ff 4c 8b 5c 24 60 4c 8b cb 44 8b c7 48 8b d6 48 8b cd 4c 89 5c 24 20 e8 6c f8 ff ff 48 8b 0d d9 8f 00 00 48 8b d8 e8 85 e6 ff ff 48 8b c3 48 8b 5c 24 40 48 8b 6c 24 48 48 8b 74 24 50 48 83 c4 30 5f c3 cc 48 89 5c 24 10 48 89 6c 24 18 48 89 74 24 20 57 48 81 ec f0 00 00 00 48 8b 0d 52 9d 00 00 48 8d 15 13 90 00 00 e8 0a a0 ff ff 33 f6 48 89 84 24 00 01 00 00 40 8a de 40 8a fe 48 3b c6 75 0f 48 b8 0e 00 00 00 00 00 00 80 e9 48 02 00 00 48 8d 94 24 00 01 00 00 48 8d 0d fb 7c 00 00 e8 6a 1a 00 00 48 bd 00 00 00 00 00 00 00 80 48 85 c5 75 ce 40 38 35 60 7c 00 00 74 54 48 8b 84 24 00 01 00 00 4c 8b c6 4c 8d 0d 7c a1 00 00 8b 48 28 ba 06 00 00 00 8d 04 49 a9 ff 0f 00 00 89 05 6e a1 00 00 41 0f 95 c0 48 c1 e8 0c 33 c9 4c 03 c0 48 8b 05 c2 9c 00 00 ff 50 28 48 85 c5 48 8b 05 45 a1 00 00 48 0f 45 c6 48 89 05 3a a1 00 00 48 8d 0d 6b a6 00 00 45 33 c0 ba d0 02 00 00 e8 3e aa ff ff 4c 8b 9c 24 00 01 00 00 48 8d 2d cf 8e 00 00 41 8b 4b 2c 45 33 c9 ba 00 00 01 00 89 0d 41 a6 00 00 41 8b 43 30 4c 8b c1 89 05 38 a6 00 00 49 8b 43 20 48 8d 4c 24 70 48 89 2d d0 a8 00 00 c6 44 24 20 01 48 89 05 cc a8 00 00 e8 73 e5 ff ff f6 05 10 a6 00 00 08 74 62 48 8b 84 24 00 01 00 00 44 8b 05 fb a5 00 00 48 89 2d 98 a8 00 00 8b 50 28 48 8d 4c 24 30 41 b1 01 c6 44 24 20 01 e8 3f e5 ff ff 48 8b 94 24 00 01 00 00 4c 8b 44 24 38 48 8b 4c 24 30 48 8b 52 18 e8 90 a8 ff ff 8b 15 be a5 00 00 48 8d 4c 24 30 41 b0 01 e8 ed 2a 00 00 48 89 35 5e a8 00 00 eb 3a 48 8b 8c 24 00 01 00 00 8b 15 9a a5 00 00 48 8d 05 2f 8e 00 00 48 89 05 30 a8 00 00 48 8b 41 18 41 b0 01 48 89 44 24 30 8b 41 28 48 8d 4c 24 30 48 89 44 24 38 e8 aa 2a 00 00 48 8b 44 24 30 81 78 28 5f 46 56 48 75 26 4c 8d 84 24 b0 00 00 00 48 8d 54 24 30 48 8d 0d 48 7b 00 00 e8 1b 30 00 00 48 3b c6 74 08 8b 05 40 a5 00 00 eb 14 8b 05 38 a5 00 00 b3 01 83 c8 02 40 8a fb 89 05 2a a5 00 00 a8 02 74 26 48 8b 15 bf a7 00 00 48 8d 4c 24 30 44 8a cf 44 8a c3 e8 df ee ff ff 8b 05 09 a5 00 00 83 e0 fd 89 05 00 a5 00 00 a8 08 75 0a 48 8d 4c 24 30 e8 06 c8 ff ff 48 8d 54 24 70 48 8d 4c 24 30 e8 cb e5 ff ff e8 42 ce ff ff 48 8d 0d 27 fc ff ff e8 8a 42 00 00 40 3a c6 75 19 48 8b 15 66 a7 00 00 48 8b 0d 4f a7 00 00 41 b1 01 45 8a c1 e8 84 ee ff ff 33 c0 4c 8d 9c 24 f0 00 00 00 49 8b 5b 18 49 8b 6b 20 49 8b 73 28 49 8b e3 5f c3 cc 48 83 25 68 8d 00 00 00 c6 05 41 9f 00 00 01 48 85 c9 74 11 48 8b 0d 9d a1 00 00 80 79 18 00 0f 94 c0 88 41 18 c3 cc cc 48 89 5c 24 08 57 48 83 ec 30 48 83 64 24 50 00 4c 8d 0d 91 e9 ff ff 4c 8d 05 ba ff ff ff 48 8b da 48 8b f9 e8 3b a2 ff ff 48 83 64 24 20 00 45 33 c9 45 33 c0 41 8d 49 01 ba 00 80 10 03 e8 e1 (XEN) Delay of 3 seconds: ..3..2..1 (XEN) 1:4599d26f-1a11-49b8--b9-1f-85-87-45-cf-f8-24: StdDefaults [0] (XEN) 2:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: FTMActiveFlag [0] (XEN) 3:ec87d643-eba4-4bb5--a1-e5-3f-3e-36-b2-0d-a9: EzFlashBiosFilePath [0] (XEN) 4:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: MonotonicCounter [0] (XEN) 5:dde1bc72-d45e-4209--ab-85-14-46-2d-2f-50-74: HobRomImage [0] (XEN) 6:ec87d643-eba4-4bb5--a1-e5-3f-3e-36-b2-0d-a9: SetupAccFeatures [0] (XEN) 7:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: FPDT_Variable [0] (XEN) 8:ec87d643-eba4-4bb5--a1-e5-3f-3e-36-b2-0d-a9: Setup [0] (XEN) 9:f3ed95df-828e-41c7--bc-a0-16-c4-19-65-a6-34: TcgInternalSyncFlag [0] (XEN) 10:c89dc9c7-5105-472c--a7-43-b1-62-1e-14-2b-41: CMOSfailflag [0] (XEN) 11:490216c0-76a-44d3--a5-36-ac-e0-5c-90-e3-86: NBMemoryLength [0] (XEN) 12:43387991-1223-7645--b5-bb-aa-76-75-c5-c8-ef: AMIMemInfo [0] (XEN) 13:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: OsIndications [0] (XEN) 14:d719b2cb-3d3a-4596--a3-bc-da-d0-0e-67-65-6f: dbx [0] (XEN) 15:d719b2cb-3d3a-4596--a3-bc-da-d0-0e-67-65-6f: db [0] (XEN) 16:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: KEK [0] (XEN) 17:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: PK [0] (XEN) 18:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: Timeout [0] (XEN) 19:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: UMAVar. [0] (XEN) 20:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: UMAVarB. [0] (XEN) 21:c3a4e49f-485f-4fd6--a2-ea-2b-c8-74-55-ad-4b: MemContext [0] (XEN) 22:ec87d643-eba4-4bb5--a1-e5-3f-3e-36-b2-0d-a9: SetupAPMFeatures [0] (XEN) 23:ec87d643-eba4-4bb5--a1-e5-3f-3e-36-b2-0d-a9: PreVgaInfo [0] (XEN) 24:560bf58a-1e0d-4d7e--95-3f-29-80-a2-61-e0-31: PNP0501_0_NV [0] (XEN) 25:560bf58a-1e0d-4d7e--95-3f-29-80-a2-61-e0-31: PNP0604_0_NV [0] (XEN) 26:560bf58a-1e0d-4d7e--95-3f-29-80-a2-61-e0-31: PNP0400_0_NV [0] (XEN) 27:560bf58a-1e0d-4d7e--95-3f-29-80-a2-61-e0-31: PNP0501_1_NV [0] (XEN) 28:560bf58a-1e0d-4d7e--95-3f-29-80-a2-61-e0-31: PNP0510_0_NV [0] (XEN) 29:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: ConOut [0] (XEN) 30:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: ConIn [0] (XEN) 31:a56074db-65fe-45f7--bd-21-2d-2b-dd-8e-96-52: LegacyDevOrder [0] (XEN) 32:a56074db-65fe-45f7--bd-21-2d-2b-dd-8e-96-52: OldLegacyDevOrder [0] (XEN) 33:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: SpdBypassData [0] (XEN) 34:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: SpdBypassSerial [0] (XEN) 35:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: MemRestoreSerialLength [0] (XEN) 36:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: MemRestoreCpuId [0] (XEN) 37:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: MemRestoreConfigId [0] (XEN) 38:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: MemRestoreTime [0] (XEN) 39:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: ModuleVersion [0] (XEN) 40:ec87d643-eba4-4bb5--a1-e5-3f-3e-36-b2-0d-a9: SetupHWMFeatures [0] (XEN) 41:c05fba7d-7a92-49e0--bc-ee-23-3b-14-dc-a8-03: VARSTORE_OCMR_SETTINGS_NAME [0] (XEN) 42:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: Lang [0] (XEN) 43:45cf35f6-d6e-4d04--85-6a-03-70-a5-b1-6f-53: DefaultBootOrder [0] (XEN) 44:3c4ead08-45ae-4315--8d-15-a6-0e-aa-8c-af-69: DefaultLegacyDevOrder [0] (XEN) 45:15a9dd61-e4f8-4a99--80-db-35-3b-13-d7-64-90: NVRAM_Verify [0] (XEN) 46:2485da8e-ded2-42cb--ac-b0-3c-e6-66-c5-5f-0c: SetupEntry [0] (XEN) 47:ec87d643-eba4-4bb5--a1-e5-3f-3e-36-b2-0d-a9: InBiosSetupFlag [0] (XEN) 48:9d0da369-540b-46f8--85-a0-2b-5f-2c-30-1e-15: EfiTime [0] (XEN) 49:b1cfc482-4cb2-4cee--9b-00-ce-25-79-ec-71-86: MemoryS3SaveNv [0] (XEN) 50:a51b41d-de21-43fe--be-27-d6-db-c9-ef-d1-04: MemoryS3SaveVol [0] (XEN) 51:a51b41d-de21-43fe--be-27-d6-db-c9-ef-d1-04: MemoryS3SaveVolLength [0] (XEN) 52:ec87d643-eba4-4bb5--a1-e5-3f-3e-36-b2-0d-a9: FirstBootFlag [0] (XEN) 53:5d6b998a-e304-4088--90-87-13-0c-91-7f-b1-ae: HiiDataSize [0] (XEN) 54:9efb5933-b856-46c2--a0-29-92-1c-ea-7b-da-2e: AmdCpuIoTrapData [0] (XEN) 55:30b98b95-dfa3-4501--a3-ce-e3-8c-18-63-84-a0: CpuS3Resume [0] (XEN) 56:af9ffd67-ec10-488a--9d-fc-6c-bf-5e-e2-2c-2e: AcpiGlobalVariable [0] (XEN) 57:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: PlatformLang [0] (XEN) 58:c811fa38-42c8-4579--a9-bb-60-e9-4e-dd-fb-34: AMITSESetup [0] (XEN) 59:93c483a1-d3fa-4e92--b4-37-73-3b-2a-34-6e-23: VARSTORE_OCMR_TIMING_SETTINGS_NAME [0] (XEN) 60:ec87d643-eba4-4bb5--a1-e5-3f-3e-36-b2-0d-a9: UsbSupport [0] (XEN) 61:7e7092f3-103-4948--a1-4c-9c-25-26-ce-77-3b: SR5690ASetup [0] (XEN) 62:d1405d16-7afc-4695--bb-12-41-45-9d-36-95-a2: NetworkStackVar [0] (XEN) 63:ec87d643-eba4-4bb5--a1-e5-3f-3e-36-b2-0d-a9: SetupHWMOneof [0] (XEN) 64:b540a530-6978-4da7--91-cb-72-07-d7-64-d2-62: FastBootOption [0] (XEN) 65:4c19049f-4137-4dd3--9c-10-8b-97-a8-3f-fd-fa: PreviousMemoryTypeInformation [0] (XEN) 66:4c19049f-4137-4dd3--9c-10-8b-97-a8-3f-fd-fa: MemoryTypeInformation [0] (XEN) 67:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: Boot0000 [0] (XEN) 68:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: Boot0002 [0] (XEN) 69:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: Boot0003 [0] (XEN) 70:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: Boot0005 [0] (XEN) 71:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: Boot0006 [0] (XEN) 72:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: BootOrder [0] (XEN) 73:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: Boot000A [0] (XEN) 74:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: Boot000B [0] (XEN) 75:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: Boot000C [0] (XEN) 76:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: Boot0008 [0] (XEN) 77:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: Boot000D [0] (XEN) 78:c3a4e49f-485f-4fd6--a2-ea-2b-c8-74-55-ad-4b: MemContextNv [0] (XEN) 79:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: Boot0009 [0] (XEN) 80:ec87d643-eba4-4bb5--a1-e5-3f-3e-36-b2-0d-a9: BootFromUSB [0] (XEN) 81:b540a530-6978-4da7--91-cb-72-07-d7-64-d2-62: LastBoot [0] (XEN) 82:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: SignatureSupport [0] (XEN) 83:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: SecureBoot [0] (XEN) 84:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: SetupMode [0] (XEN) 85:4bafc2b4-2dc-4104--b2-36-d6-f1-b9-8d-9e-84: S3SS [0] (XEN) 86:ec87d643-eba4-4bb5--a1-e5-3f-3e-36-b2-0d-a9: SetupCpuFeatures [0] (XEN) 87:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: OsIndicationsSupported [0] (XEN) 88:ec87d643-eba4-4bb5--a1-e5-3f-3e-36-b2-0d-a9: UsbMassDevNum [0] (XEN) 89:ec87d643-eba4-4bb5--a1-e5-3f-3e-36-b2-0d-a9: UsbMassDevValid [0] (XEN) 90:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: SB_USB_POINT [0] (XEN) 91:c811fa38-42c8-4579--a9-bb-60-e9-4e-dd-fb-34: USB_POINT [0] (XEN) 92:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: ConOutDev [0] (XEN) 93:560bf58a-1e0d-4d7e--95-3f-29-80-a2-61-e0-31: PNP0501_0_VV [0] (XEN) 94:560bf58a-1e0d-4d7e--95-3f-29-80-a2-61-e0-31: PNP0604_0_VV [0] (XEN) 95:560bf58a-1e0d-4d7e--95-3f-29-80-a2-61-e0-31: PNP0400_0_VV [0] (XEN) 96:560bf58a-1e0d-4d7e--95-3f-29-80-a2-61-e0-31: PNP0501_1_VV [0] (XEN) 97:560bf58a-1e0d-4d7e--95-3f-29-80-a2-61-e0-31: PNP0510_0_VV [0] (XEN) 98:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: ConInDev [0] (XEN) 99:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: HpcModeBU [0] (XEN) 100:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: PlatformLangCodes [0] (XEN) 101:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: LangCodes [0] (XEN) 102:8be4df61-93ca-11d2--aa-0d-00-e0-98-03-2b-8c: BootCurrent [0] (XEN) 103:1b838190-4625-4ead--ab-c9-cd-5e-6a-f1-8f-e0: HiiDB [0] (XEN) 104:EFI_ERROR: 800000000000000e .. and translation: Code: 48 89 5c 24 08 48 89 74 24 10 57 48 83 ec 20 48 8b f1 48 8b 0d 87 90 00 00 49 8b d8 80 39 00 48 8b fa 74 0c 48 b8 0f 00 00 00 00 00 00 80 eb 25 e8 cb e6 ff ff 4c 8b c3 48 8b d7 48 8b ce e8 51 f8 ff ff 48 8b 0d 56 90 00 00 48 8b d8 e8 02 e7 ff ff 48 8b c3 48 8b 5c 24 30 48 8b 74 24 38 48 83 c4 20 5f c3 cc cc cc 48 89 5c 24 08 48 89 6c 24 10 48 89 74 24 18 57 48 83 ec 30 48 8b e9 48 8b 0d 1a 90 00 00 49 8b d9 80 39 00 41 8b f8 48 8b f2 74 0c 48 b8 0f 00 00 00 00 00 00 80 eb 32 e8 5b e6 ff ff 4c 8b 5c 24 60 4c 8b cb 44 8b c7 48 8b d6 48 8b cd 4c 89 5c 24 20 e8 6c f8 ff ff 48 8b 0d d9 8f 00 00 48 8b d8 e8 85 e6 ff ff 48 8b c3 48 8b 5c 24 40 48 8b 6c 24 48 48 8b 74 24 50 48 83 c4 30 5f c3 cc 48 89 5c 24 10 48 89 6c 24 18 48 89 74 24 20 57 48 81 ec f0 00 00 00 48 8b 0d 52 9d 00 00 48 8d 15 13 90 00 00 e8 0a a0 ff ff 33 f6 48 89 84 24 00 01 00 00 40 8a de 40 8a fe 48 3b c6 75 0f 48 b8 0e 00 00 00 00 00 00 80 e9 48 02 00 00 48 8d 94 24 00 01 00 00 48 8d 0d fb 7c 00 00 e8 6a 1a 00 00 48 bd 00 00 00 00 00 00 00 80 48 85 c5 75 ce 40 38 35 60 7c 00 00 74 54 48 8b 84 24 00 01 00 00 4c 8b c6 4c 8d 0d 7c a1 00 00 8b 48 28 ba 06 00 00 00 8d 04 49 a9 ff 0f 00 00 89 05 6e a1 00 00 41 0f 95 c0 48 c1 e8 0c 33 c9 4c 03 c0 48 8b 05 c2 9c 00 00 ff 50 28 48 85 c5 48 8b 05 45 a1 00 00 48 0f 45 c6 48 89 05 3a a1 00 00 48 8d 0d 6b a6 00 00 45 33 c0 ba d0 02 00 00 e8 3e aa ff ff 4c 8b 9c 24 00 01 00 00 48 8d 2d cf 8e 00 00 41 8b 4b 2c 45 33 c9 ba 00 00 01 00 89 0d 41 a6 00 00 41 8b 43 30 4c 8b c1 89 05 38 a6 00 00 49 8b 43 20 48 8d 4c 24 70 48 89 2d d0 a8 00 00 c6 44 24 20 01 48 89 05 cc a8 00 00 e8 73 e5 ff ff f6 05 10 a6 00 00 08 74 62 48 8b 84 24 00 01 00 00 44 8b 05 fb a5 00 00 48 89 2d 98 a8 00 00 8b 50 28 48 8d 4c 24 30 41 b1 01 c6 44 24 20 01 e8 3f e5 ff ff 48 8b 94 24 00 01 00 00 4c 8b 44 24 38 48 8b 4c 24 30 48 8b 52 18 e8 90 a8 ff ff 8b 15 be a5 00 00 48 8d 4c 24 30 41 b0 01 e8 ed 2a 00 00 48 89 35 5e a8 00 00 eb 3a 48 8b 8c 24 00 01 00 00 8b 15 9a a5 00 00 48 8d 05 2f 8e 00 00 48 89 05 30 a8 00 00 48 8b 41 18 41 b0 01 48 89 44 24 30 8b 41 28 48 8d 4c 24 30 48 89 44 24 38 e8 aa 2a 00 00 48 8b 44 24 30 81 78 28 5f 46 56 48 75 26 4c 8d 84 24 b0 00 00 00 48 8d 54 24 30 48 8d 0d 48 7b 00 00 e8 1b 30 00 00 48 3b c6 74 08 8b 05 40 a5 00 00 eb 14 8b 05 38 a5 00 00 b3 01 83 c8 02 40 8a fb 89 05 2a a5 00 00 a8 02 74 26 48 8b 15 bf a7 00 00 48 8d 4c 24 30 44 8a cf 44 8a c3 e8 df ee ff ff 8b 05 09 a5 00 00 83 e0 fd 89 05 00 a5 00 00 a8 08 75 0a 48 8d 4c 24 30 e8 06 c8 ff ff 48 8d 54 24 70 48 8d 4c 24 30 e8 cb e5 ff ff e8 42 ce ff ff 48 8d 0d 27 fc ff ff e8 8a 42 00 00 40 3a c6 75 19 48 8b 15 66 a7 00 00 48 8b 0d 4f a7 00 00 41 b1 01 45 8a c1 e8 84 ee ff ff 33 c0 4c 8d 9c 24 f0 00 00 00 49 8b 5b 18 49 8b 6b 20 49 8b 73 28 49 8b e3 5f c3 cc 48 83 25 68 8d 00 00 00 c6 05 41 9f 00 00 01 48 85 c9 74 11 48 8b 0d 9d a1 00 00 80 79 18 00 0f 94 c0 88 41 18 c3 cc cc 48 89 5c 24 08 57 48 83 ec 30 48 83 64 24 50 00 4c 8d 0d 91 e9 ff ff 4c 8d 05 ba ff ff ff 48 8b da 48 8b f9 e8 3b a2 ff ff 48 83 64 24 20 00 45 33 c9 45 33 c0 41 8d 49 01 ba 00 80 10 03 e8 e1 Code starting with the faulting instruction =========================================== 0: 48 89 5c 24 08 mov %rbx,0x8(%rsp) 5: 48 89 74 24 10 mov %rsi,0x10(%rsp) a: 57 push %rdi b: 48 83 ec 20 sub $0x20,%rsp f: 48 8b f1 mov %rcx,%rsi 12: 48 8b 0d 87 90 00 00 mov 0x9087(%rip),%rcx # 0x90a0 19: 49 8b d8 mov %r8,%rbx 1c: 80 39 00 cmpb $0x0,(%rcx) 1f: 48 8b fa mov %rdx,%rdi 22: 74 0c je 0x30 24: 48 b8 0f 00 00 00 00 movabs $0x800000000000000f,%rax 2b: 00 00 80 2e: eb 25 jmp 0x55 30: e8 cb e6 ff ff callq 0xffffffffffffe700 35: 4c 8b c3 mov %rbx,%r8 38: 48 8b d7 mov %rdi,%rdx 3b: 48 8b ce mov %rsi,%rcx 3e: e8 51 f8 ff ff callq 0xfffffffffffff894 43: 48 8b 0d 56 90 00 00 mov 0x9056(%rip),%rcx # 0x90a0 4a: 48 8b d8 mov %rax,%rbx 4d: e8 02 e7 ff ff callq 0xffffffffffffe754 52: 48 8b c3 mov %rbx,%rax 55: 48 8b 5c 24 30 mov 0x30(%rsp),%rbx 5a: 48 8b 74 24 38 mov 0x38(%rsp),%rsi 5f: 48 83 c4 20 add $0x20,%rsp 63: 5f pop %rdi 64: c3 retq 65: cc int3 66: cc int3 67: cc int3 68: 48 89 5c 24 08 mov %rbx,0x8(%rsp) 6d: 48 89 6c 24 10 mov %rbp,0x10(%rsp) 72: 48 89 74 24 18 mov %rsi,0x18(%rsp) 77: 57 push %rdi 78: 48 83 ec 30 sub $0x30,%rsp 7c: 48 8b e9 mov %rcx,%rbp 7f: 48 8b 0d 1a 90 00 00 mov 0x901a(%rip),%rcx # 0x90a0 86: 49 8b d9 mov %r9,%rbx 89: 80 39 00 cmpb $0x0,(%rcx) 8c: 41 8b f8 mov %r8d,%edi 8f: 48 8b f2 mov %rdx,%rsi 92: 74 0c je 0xa0 94: 48 b8 0f 00 00 00 00 movabs $0x800000000000000f,%rax 9b: 00 00 80 9e: eb 32 jmp 0xd2 a0: e8 5b e6 ff ff callq 0xffffffffffffe700 a5: 4c 8b 5c 24 60 mov 0x60(%rsp),%r11 aa: 4c 8b cb mov %rbx,%r9 ad: 44 8b c7 mov %edi,%r8d b0: 48 8b d6 mov %rsi,%rdx b3: 48 8b cd mov %rbp,%rcx b6: 4c 89 5c 24 20 mov %r11,0x20(%rsp) bb: e8 6c f8 ff ff callq 0xfffffffffffff92c c0: 48 8b 0d d9 8f 00 00 mov 0x8fd9(%rip),%rcx # 0x90a0 c7: 48 8b d8 mov %rax,%rbx ca: e8 85 e6 ff ff callq 0xffffffffffffe754 cf: 48 8b c3 mov %rbx,%rax d2: 48 8b 5c 24 40 mov 0x40(%rsp),%rbx d7: 48 8b 6c 24 48 mov 0x48(%rsp),%rbp dc: 48 8b 74 24 50 mov 0x50(%rsp),%rsi e1: 48 83 c4 30 add $0x30,%rsp e5: 5f pop %rdi e6: c3 retq e7: cc int3 e8: 48 89 5c 24 10 mov %rbx,0x10(%rsp) ed: 48 89 6c 24 18 mov %rbp,0x18(%rsp) f2: 48 89 74 24 20 mov %rsi,0x20(%rsp) f7: 57 push %rdi f8: 48 81 ec f0 00 00 00 sub $0xf0,%rsp ff: 48 8b 0d 52 9d 00 00 mov 0x9d52(%rip),%rcx # 0x9e58 106: 48 8d 15 13 90 00 00 lea 0x9013(%rip),%rdx # 0x9120 10d: e8 0a a0 ff ff callq 0xffffffffffffa11c 112: 33 f6 xor %esi,%esi 114: 48 89 84 24 00 01 00 mov %rax,0x100(%rsp) 11b: 00 11c: 40 8a de mov %sil,%bl 11f: 40 8a fe mov %sil,%dil 122: 48 3b c6 cmp %rsi,%rax 125: 75 0f jne 0x136 127: 48 b8 0e 00 00 00 00 movabs $0x800000000000000e,%rax 12e: 00 00 80 131: e9 48 02 00 00 jmpq 0x37e 136: 48 8d 94 24 00 01 00 lea 0x100(%rsp),%rdx 13d: 00 13e: 48 8d 0d fb 7c 00 00 lea 0x7cfb(%rip),%rcx # 0x7e40 145: e8 6a 1a 00 00 callq 0x1bb4 14a: 48 bd 00 00 00 00 00 movabs $0x8000000000000000,%rbp 151: 00 00 80 154: 48 85 c5 test %rax,%rbp 157: 75 ce jne 0x127 159: 40 38 35 60 7c 00 00 cmp %sil,0x7c60(%rip) # 0x7dc0 160: 74 54 je 0x1b6 162: 48 8b 84 24 00 01 00 mov 0x100(%rsp),%rax 169: 00 16a: 4c 8b c6 mov %rsi,%r8 16d: 4c 8d 0d 7c a1 00 00 lea 0xa17c(%rip),%r9 # 0xa2f0 174: 8b 48 28 mov 0x28(%rax),%ecx 177: ba 06 00 00 00 mov $0x6,%edx 17c: 8d 04 49 lea (%rcx,%rcx,2),%eax 17f: a9 ff 0f 00 00 test $0xfff,%eax 184: 89 05 6e a1 00 00 mov %eax,0xa16e(%rip) # 0xa2f8 18a: 41 0f 95 c0 setne %r8b 18e: 48 c1 e8 0c shr $0xc,%rax 192: 33 c9 xor %ecx,%ecx 194: 4c 03 c0 add %rax,%r8 197: 48 8b 05 c2 9c 00 00 mov 0x9cc2(%rip),%rax # 0x9e60 19e: ff 50 28 callq *0x28(%rax) 1a1: 48 85 c5 test %rax,%rbp 1a4: 48 8b 05 45 a1 00 00 mov 0xa145(%rip),%rax # 0xa2f0 1ab: 48 0f 45 c6 cmovne %rsi,%rax 1af: 48 89 05 3a a1 00 00 mov %rax,0xa13a(%rip) # 0xa2f0 1b6: 48 8d 0d 6b a6 00 00 lea 0xa66b(%rip),%rcx # 0xa828 1bd: 45 33 c0 xor %r8d,%r8d 1c0: ba d0 02 00 00 mov $0x2d0,%edx 1c5: e8 3e aa ff ff callq 0xffffffffffffac08 1ca: 4c 8b 9c 24 00 01 00 mov 0x100(%rsp),%r11 1d1: 00 1d2: 48 8d 2d cf 8e 00 00 lea 0x8ecf(%rip),%rbp # 0x90a8 1d9: 41 8b 4b 2c mov 0x2c(%r11),%ecx 1dd: 45 33 c9 xor %r9d,%r9d 1e0: ba 00 00 01 00 mov $0x10000,%edx 1e5: 89 0d 41 a6 00 00 mov %ecx,0xa641(%rip) # 0xa82c 1eb: 41 8b 43 30 mov 0x30(%r11),%eax 1ef: 4c 8b c1 mov %rcx,%r8 1f2: 89 05 38 a6 00 00 mov %eax,0xa638(%rip) # 0xa830 1f8: 49 8b 43 20 mov 0x20(%r11),%rax 1fc: 48 8d 4c 24 70 lea 0x70(%rsp),%rcx 201: 48 89 2d d0 a8 00 00 mov %rbp,0xa8d0(%rip) # 0xaad8 208: c6 44 24 20 01 movb $0x1,0x20(%rsp) 20d: 48 89 05 cc a8 00 00 mov %rax,0xa8cc(%rip) # 0xaae0 214: e8 73 e5 ff ff callq 0xffffffffffffe78c 219: f6 05 10 a6 00 00 08 testb $0x8,0xa610(%rip) # 0xa830 220: 74 62 je 0x284 222: 48 8b 84 24 00 01 00 mov 0x100(%rsp),%rax 229: 00 22a: 44 8b 05 fb a5 00 00 mov 0xa5fb(%rip),%r8d # 0xa82c 231: 48 89 2d 98 a8 00 00 mov %rbp,0xa898(%rip) # 0xaad0 238: 8b 50 28 mov 0x28(%rax),%edx 23b: 48 8d 4c 24 30 lea 0x30(%rsp),%rcx 240: 41 b1 01 mov $0x1,%r9b 243: c6 44 24 20 01 movb $0x1,0x20(%rsp) 248: e8 3f e5 ff ff callq 0xffffffffffffe78c 24d: 48 8b 94 24 00 01 00 mov 0x100(%rsp),%rdx 254: 00 255: 4c 8b 44 24 38 mov 0x38(%rsp),%r8 25a: 48 8b 4c 24 30 mov 0x30(%rsp),%rcx 25f: 48 8b 52 18 mov 0x18(%rdx),%rdx 263: e8 90 a8 ff ff callq 0xffffffffffffaaf8 268: 8b 15 be a5 00 00 mov 0xa5be(%rip),%edx # 0xa82c 26e: 48 8d 4c 24 30 lea 0x30(%rsp),%rcx 273: 41 b0 01 mov $0x1,%r8b 276: e8 ed 2a 00 00 callq 0x2d68 27b: 48 89 35 5e a8 00 00 mov %rsi,0xa85e(%rip) # 0xaae0 282: eb 3a jmp 0x2be 284: 48 8b 8c 24 00 01 00 mov 0x100(%rsp),%rcx 28b: 00 28c: 8b 15 9a a5 00 00 mov 0xa59a(%rip),%edx # 0xa82c 292: 48 8d 05 2f 8e 00 00 lea 0x8e2f(%rip),%rax # 0x90c8 299: 48 89 05 30 a8 00 00 mov %rax,0xa830(%rip) # 0xaad0 2a0: 48 8b 41 18 mov 0x18(%rcx),%rax 2a4: 41 b0 01 mov $0x1,%r8b 2a7: 48 89 44 24 30 mov %rax,0x30(%rsp) 2ac: 8b 41 28 mov 0x28(%rcx),%eax 2af: 48 8d 4c 24 30 lea 0x30(%rsp),%rcx 2b4: 48 89 44 24 38 mov %rax,0x38(%rsp) 2b9: e8 aa 2a 00 00 callq 0x2d68 2be: 48 8b 44 24 30 mov 0x30(%rsp),%rax 2c3: 81 78 28 5f 46 56 48 cmpl $0x4856465f,0x28(%rax) 2ca: 75 26 jne 0x2f2 2cc: 4c 8d 84 24 b0 00 00 lea 0xb0(%rsp),%r8 2d3: 00 2d4: 48 8d 54 24 30 lea 0x30(%rsp),%rdx 2d9: 48 8d 0d 48 7b 00 00 lea 0x7b48(%rip),%rcx # 0x7e28 2e0: e8 1b 30 00 00 callq 0x3300 2e5: 48 3b c6 cmp %rsi,%rax 2e8: 74 08 je 0x2f2 2ea: 8b 05 40 a5 00 00 mov 0xa540(%rip),%eax # 0xa830 2f0: eb 14 jmp 0x306 2f2: 8b 05 38 a5 00 00 mov 0xa538(%rip),%eax # 0xa830 2f8: b3 01 mov $0x1,%bl 2fa: 83 c8 02 or $0x2,%eax 2fd: 40 8a fb mov %bl,%dil 300: 89 05 2a a5 00 00 mov %eax,0xa52a(%rip) # 0xa830 306: a8 02 test $0x2,%al 308: 74 26 je 0x330 30a: 48 8b 15 bf a7 00 00 mov 0xa7bf(%rip),%rdx # 0xaad0 311: 48 8d 4c 24 30 lea 0x30(%rsp),%rcx 316: 44 8a cf mov %dil,%r9b 319: 44 8a c3 mov %bl,%r8b 31c: e8 df ee ff ff callq 0xfffffffffffff200 321: 8b 05 09 a5 00 00 mov 0xa509(%rip),%eax # 0xa830 327: 83 e0 fd and $0xfffffffd,%eax 32a: 89 05 00 a5 00 00 mov %eax,0xa500(%rip) # 0xa830 330: a8 08 test $0x8,%al 332: 75 0a jne 0x33e 334: 48 8d 4c 24 30 lea 0x30(%rsp),%rcx 339: e8 06 c8 ff ff callq 0xffffffffffffcb44 33e: 48 8d 54 24 70 lea 0x70(%rsp),%rdx 343: 48 8d 4c 24 30 lea 0x30(%rsp),%rcx 348: e8 cb e5 ff ff callq 0xffffffffffffe918 34d: e8 42 ce ff ff callq 0xffffffffffffd194 352: 48 8d 0d 27 fc ff ff lea -0x3d9(%rip),%rcx # 0xffffffffffffff80 359: e8 8a 42 00 00 callq 0x45e8 35e: 40 3a c6 cmp %sil,%al 361: 75 19 jne 0x37c 363: 48 8b 15 66 a7 00 00 mov 0xa766(%rip),%rdx # 0xaad0 36a: 48 8b 0d 4f a7 00 00 mov 0xa74f(%rip),%rcx # 0xaac0 371: 41 b1 01 mov $0x1,%r9b 374: 45 8a c1 mov %r9b,%r8b 377: e8 84 ee ff ff callq 0xfffffffffffff200 37c: 33 c0 xor %eax,%eax 37e: 4c 8d 9c 24 f0 00 00 lea 0xf0(%rsp),%r11 385: 00 386: 49 8b 5b 18 mov 0x18(%r11),%rbx 38a: 49 8b 6b 20 mov 0x20(%r11),%rbp 38e: 49 8b 73 28 mov 0x28(%r11),%rsi 392: 49 8b e3 mov %r11,%rsp 395: 5f pop %rdi 396: c3 retq 397: cc int3 398: 48 83 25 68 8d 00 00 andq $0x0,0x8d68(%rip) # 0x9108 39f: 00 3a0: c6 05 41 9f 00 00 01 movb $0x1,0x9f41(%rip) # 0xa2e8 3a7: 48 85 c9 test %rcx,%rcx 3aa: 74 11 je 0x3bd 3ac: 48 8b 0d 9d a1 00 00 mov 0xa19d(%rip),%rcx # 0xa550 3b3: 80 79 18 00 cmpb $0x0,0x18(%rcx) 3b7: 0f 94 c0 sete %al 3ba: 88 41 18 mov %al,0x18(%rcx) 3bd: c3 retq 3be: cc int3 3bf: cc int3 3c0: 48 89 5c 24 08 mov %rbx,0x8(%rsp) 3c5: 57 push %rdi 3c6: 48 83 ec 30 sub $0x30,%rsp 3ca: 48 83 64 24 50 00 andq $0x0,0x50(%rsp) 3d0: 4c 8d 0d 91 e9 ff ff lea -0x166f(%rip),%r9 # 0xffffffffffffed68 3d7: 4c 8d 05 ba ff ff ff lea -0x46(%rip),%r8 # 0x398 3de: 48 8b da mov %rdx,%rbx 3e1: 48 8b f9 mov %rcx,%rdi 3e4: e8 3b a2 ff ff callq 0xffffffffffffa624 3e9: 48 83 64 24 20 00 andq $0x0,0x20(%rsp) 3ef: 45 33 c9 xor %r9d,%r9d 3f2: 45 33 c0 xor %r8d,%r8d 3f5: 41 8d 49 01 lea 0x1(%r9),%ecx 3f9: ba 00 80 10 03 mov $0x3108000,%edx 3fe: e8 .byte 0xe8 3ff: e1 .byte 0xe1 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-26 16:27 EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues Konrad Rzeszutek Wilk @ 2015-01-26 16:36 ` Andrew Cooper 2015-01-26 17:28 ` Konrad Rzeszutek Wilk [not found] ` <54C680C90200007800059907@mail.emea.novell.com> 1 sibling, 1 reply; 27+ messages in thread From: Andrew Cooper @ 2015-01-26 16:36 UTC (permalink / raw) To: Konrad Rzeszutek Wilk, xen-devel, daniel.kiper, jbeulich On 26/01/15 16:27, Konrad Rzeszutek Wilk wrote: > Hey Jan, Andrew, > > I am hoping you can help me in directing me where I ought to go next > in debugging this. > > This is a Lenovo Thinkpad x230 with the latest BIOS and Xen 4.6 (todays > 'staging' + my patches). Initially when I installed Xen the first time > it would hang when loading the efi_vars module in Linux. Debugging > a bit more and I found out that the issue is that we crash when > calling GetNextVariableName (works fine with GetTime/SetTime, hand't > tried GetVariable). > > I decided to implement in the hypervisor a little loop that would > call GetNextVariableName and it works on my ASUS M5A87 board nicely. > (attached at the bottom for comparison) > > However on this laptop it keeps on crashing. I've also added > a bit of code to get the binary code from the GetNextVariableName > to see if it looks legit - and it looks OK (obviously different > from what the ASUS has implemented). > > Anyhow I am bit stuck: > 1) It works with Linux, so what is it that Linux does that > Xen does not? > > 2). I can't make sense of the stack trace. The efi firmware doesn't use frame pointers, but Xen does, which causes its stack tracing to get confused. This is on my todo list to fix since the last stack trace you submitted. You could see about creating a debug xen with frame_pointer=n during the build, which will cause Xen to use the non-frame pointer aware stack trace algorithm. That would help analyse the issue. ~Andrew ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-26 16:36 ` Andrew Cooper @ 2015-01-26 17:28 ` Konrad Rzeszutek Wilk 0 siblings, 0 replies; 27+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-01-26 17:28 UTC (permalink / raw) To: Andrew Cooper; +Cc: daniel.kiper, xen-devel, jbeulich On Mon, Jan 26, 2015 at 04:36:03PM +0000, Andrew Cooper wrote: > On 26/01/15 16:27, Konrad Rzeszutek Wilk wrote: > > Hey Jan, Andrew, > > > > I am hoping you can help me in directing me where I ought to go next > > in debugging this. > > > > This is a Lenovo Thinkpad x230 with the latest BIOS and Xen 4.6 (todays > > 'staging' + my patches). Initially when I installed Xen the first time > > it would hang when loading the efi_vars module in Linux. Debugging > > a bit more and I found out that the issue is that we crash when > > calling GetNextVariableName (works fine with GetTime/SetTime, hand't > > tried GetVariable). > > > > I decided to implement in the hypervisor a little loop that would > > call GetNextVariableName and it works on my ASUS M5A87 board nicely. > > (attached at the bottom for comparison) > > > > However on this laptop it keeps on crashing. I've also added > > a bit of code to get the binary code from the GetNextVariableName > > to see if it looks legit - and it looks OK (obviously different > > from what the ASUS has implemented). > > > > Anyhow I am bit stuck: > > 1) It works with Linux, so what is it that Linux does that > > Xen does not? > > > > 2). I can't make sense of the stack trace. > > The efi firmware doesn't use frame pointers, but Xen does, which causes > its stack tracing to get confused. This is on my todo list to fix since > the last stack trace you submitted. > > You could see about creating a debug xen with frame_pointer=n during the > build, which will cause Xen to use the non-frame pointer aware stack > trace algorithm. > > That would help analyse the issue. Got a bit further. See for fun my inline comments. (XEN) 1:----[ Xen-4.6-unstable x86_64 debug=n Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e008:[<000000000000000f>] 000000000000000f (XEN) RFLAGS: 0000000000010207 CONTEXT: hypervisor (XEN) rax: 00000000cfdba230 rbx: ffff830216b3aa00 rcx: 000000000000001f (XEN) rdx: 00000000d6995ed0 rsi: 0000000000150670 rdi: ffff830216b3aa00 (XEN) rbp: ffff82d080457de8 rsp: ffff82d080457d50 r8: ffff82d080457df0 (XEN) r9: 0000000000008000 r10: ffff82d080457c5c r11: 00000000db002700 (XEN) r12: ffff82d080457df0 r13: 0000000000000000 r14: 0000000000000000 (XEN) r15: 00000000d1079000 cr0: 0000000080050033 cr4: 00000000001506f0 (XEN) cr3: 0000000216b3d000 cr2: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Xen stack trace from rsp=ffff82d080457d50: (XEN) 0000000068f00002 00000000d6994d77 ffff82d080498b30 0000000000000206 (XEN) 00000000d1079000 ffff830216b39080 ffff830216b3a580 ffff82d080457df8 (XEN) 0000000216b3d000 ffff82d080229c7a ffff830216b3aa00 ffff830216b39080 (XEN) 0000000000150670 ffff82d080229c4a 0000000000000002 0000000100000008 (XEN) ffff82d080457df0 ffff82d080457de8 ffff82d080269c00 0000000000000400 (XEN) ffff82d080457e40 ffff82d080457e00 0000000000000003 ffff830216b4a4f0 (XEN) 0000000000000002 0000000000000008 0000000000000003 ffff8300d124b000 (XEN) ffff82d080269c00 ffff82d0804259b6 ffff8300d124b000 ffff8300d124afa0 (XEN) 00007d2f00000002 ffff8300d123abe5 00000000012b0000 000000021ab35000 (XEN) 0000000000000000 00000000ffffffff 000000000021e600 0000000000000000 (XEN) 00000000d124afa0 ffffffd080499780 0000000000499780 00000000012b0fff (XEN) 0000000000100000 0058bf9000000000 0000000800000000 000000010000006e (XEN) 0000000000000003 00000000000002f8 0000000000000000 00000000d123a240 (XEN) 00000000d0793408 00000000d0eff3e8 0000000000057000 00000000fed20000 (XEN) 0000000000002960 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<000000000000000f>] 000000000000000f (XEN) [<ffff82d080229c7a>] efi_debug+0x24a/0x3c0 (XEN) [<ffff82d080229c4a>] efi_debug+0x21a/0x3c0 (XEN) [<ffff82d0804259b6>] __start_xen+0x25b6/0x3bc0 (XEN) Which is: 0x5a6 <efi_debug+550>: mov 0x0(%rip),%rax # 0x5ad <efi_debug+557> 0x5ad <efi_debug+557>: movq $0x400,0x28(%rsp) 0x5b6 <efi_debug+566>: sub $0x20,%rsp 0x5ba <efi_debug+570>: mov 0x30(%rsp),%r8 0x5bf <efi_debug+575>: mov 0x38(%rsp),%rcx 0x5c4 <efi_debug+580>: mov %rbx,%rdx 0x5c7 <efi_debug+583>: callq *0x50(%rax) 0x5ca <efi_debug+586>: add $0x20,%rsp (0x24a = 586 in decimal) And this is the EFI code: 0: 48 89 5c 24 08 mov %rbx,0x8(%rsp) 5: 48 89 6c 24 10 mov %rbp,0x10(%rsp) a: 48 89 74 24 18 mov %rsi,0x18(%rsp) f: 57 push %rdi 10: 41 54 push %r12 12: 41 55 push %r13 14: 48 83 ec 20 sub $0x20,%rsp 18: 45 33 ed xor %r13d,%r13d 1b: 48 85 c9 test %rcx,%rcx 1e: 4d 8b e0 mov %r8,%r12 [From above r8 is ffff82d080457df0, and r12 = ffff82d080457df0 so it gets past here] 21: 48 8b fa mov %rdx,%rdi 24: 48 8b e9 mov %rcx,%rbp 27: 0f 84 09 01 00 00 je 0x136 2d: 48 85 d2 test %rdx,%rdx 30: 0f 84 00 01 00 00 je 0x136 36: 4d 85 c0 test %r8,%r8 39: 0f 84 f7 00 00 00 je 0x136 [if anything is wrong @136 is the reutnr of EFI_INVALID_PARAMETER] 3f: 48 8b 05 76 11 00 00 mov 0x1176(%rip),%rax # 0x11bc 46: 48 8d 15 af 11 00 00 lea 0x11af(%rip),%rdx # 0x11fc Looks like I need to ingest in my debug code more code to cover 0x11bc and further. 4d: 48 8b c8 mov %rax,%rcx [so if rax has 00000000cfdba230, rcx should have the same, but it looks to be 000000000000001f, so perhaps we crashed in the 'lea' code? Or we ended up trying to execute below and in there we blew up?] 50: ff 50 20 callq *0x20(%rax) [Especially as we seem to pick some structure and call that, rax has 00000000cfdba230 so perhaps that is where we call, however the memmap has: (XEN) 00000cfdba000-00000cfdcffff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000cfdd0000-00000cffd1fff type=0 attr=000000000000000f (XEN) .. skipped! and Linux has: [ 0.000000] efi: mem22: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x00000000cfdba000-0x00000000cfdd0000) (0MB) 53: 80 3d a2 11 00 00 01 cmpb $0x1,0x11a2(%rip) # 0x11fc 5a: 75 1b jne 0x77 5c: 48 8b 05 81 11 00 00 mov 0x1181(%rip),%rax # 0x11e4 63: 4d 8b c4 mov %r12,%r8 66: 48 8b d7 mov %rdi,%rdx 69: 48 8b cd mov %rbp,%rcx 6c: ff 50 08 callq *0x8(%rax) 6f: 48 8b d8 mov %rax,%rbx 72: e9 ba 00 00 00 jmpq 0x131 77: 48 8b cf mov %rdi,%rcx 7a: e8 bd 0f 00 00 callq 0x103c 7f: 48 3d 00 01 00 00 cmp $0x100,%rax 85: 0f 87 ab 00 00 00 ja 0x136 8b: 44 38 2d c2 10 00 00 cmp %r13b,0x10c2(%rip) # 0x1154 92: 75 12 jne 0xa6 94: 48 8b 05 d1 10 00 00 mov 0x10d1(%rip),%rax # 0x116c 9b: b9 1f 00 00 00 mov $0x1f,%ecx ... 136: 48 b8 02 00 00 00 00 movabs $0x8000000000000002,%rax 13d: 00 00 80 140: 48 8b 5c 24 40 mov 0x40(%rsp),%rbx 145: 48 8b 6c 24 48 mov 0x48(%rsp),%rbp 14a: 48 8b 74 24 50 mov 0x50(%rsp),%rsi 14f: 48 83 c4 20 add $0x20,%rsp 153: 41 5d pop %r13 155: 41 5c pop %r12 157: 5f pop %rdi 158: c3 retq 159: cc int3 15a: cc int3 15b: cc int3 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <54C680C90200007800059907@mail.emea.novell.com>]
[parent not found: <20150127000247.GU3473@olila.local.net-space.pl>]
[parent not found: <54C6DCB7.3060206@citrix.com>]
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues [not found] ` <54C6DCB7.3060206@citrix.com> @ 2015-01-27 7:54 ` Jan Beulich 2015-01-27 14:26 ` Konrad Rzeszutek Wilk 2015-01-27 20:18 ` Daniel Kiper 0 siblings, 2 replies; 27+ messages in thread From: Jan Beulich @ 2015-01-27 7:54 UTC (permalink / raw) To: Andrew Cooper, Daniel Kiper, Konrad Rzeszutek Wilk; +Cc: xen-devel (re-adding xen-devel) >>> On 27.01.15 at 01:32, <andrew.cooper3@citrix.com> wrote: > On 27/01/2015 00:02, Daniel Kiper wrote: >> On Mon, Jan 26, 2015 at 05:00:41PM +0000, Jan Beulich wrote: >>>>>> On 26.01.15 at 17:27, <konrad.wilk@oracle.com> wrote: >>>> Anyhow I am bit stuck: >>>> 1) It works with Linux, so what is it that Linux does that >>>> Xen does not? >>> They map more than just what is marked for runtime use. >> IIRC, Linux maps boot services unconditionally (and states in comment >> that this is not in line with spec). We do not have such mechanism. >> Could we ease life of our users and add a boot option (e.g. map-efi-bs) >> which will enforce mapping of BS regions on platforms with buggy EFI/UEFI >> implementations? We should not penalize owners of such hardware because >> they are not guilty of these crazy bugs. We should educate firmware devs... >> Ehh... Please, do not curse at me. I remember discussion about EFI reset >> stuff which happened here a few days ago. > > While, in principle, I would like to take a tough stand against buggy > firmware, the truth is that firmware is always going to be buggy, and > many users are going to be in a position where their buggy firmware is > not going to be fixed by their vendors. Much as I would prefer not to, > I feel that the only rational course of action to take is to behave like > Linux in cases like this. > > Therefore, I am a begrudgingly +1 "work around EFI firmware bugs", > despite it being the wrong pragmatic thing to do. And I agree that we will need to accept in such workarounds. But two remarks to whoever is going to implement it: We already have the efi-rs workaround option - we should deprecate that one, and have a consolidated efi= one instead, covering the case here too. Plus the issue here is not just a matter of mapping BS memory, but also not making it available to the allocator. That in turn may yield problems with the conversion of the EFI memory map to E820 form, both because of the number of entries needed, and because that conversion happens _before_ the normal command line parsing. Jan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-27 7:54 ` Jan Beulich @ 2015-01-27 14:26 ` Konrad Rzeszutek Wilk 2015-01-27 16:17 ` Jan Beulich 2015-01-27 20:18 ` Daniel Kiper 1 sibling, 1 reply; 27+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-01-27 14:26 UTC (permalink / raw) To: Jan Beulich; +Cc: Andrew Cooper, Daniel Kiper, xen-devel On Tue, Jan 27, 2015 at 07:54:30AM +0000, Jan Beulich wrote: > (re-adding xen-devel) > > >>> On 27.01.15 at 01:32, <andrew.cooper3@citrix.com> wrote: > > On 27/01/2015 00:02, Daniel Kiper wrote: > >> On Mon, Jan 26, 2015 at 05:00:41PM +0000, Jan Beulich wrote: > >>>>>> On 26.01.15 at 17:27, <konrad.wilk@oracle.com> wrote: > >>>> Anyhow I am bit stuck: > >>>> 1) It works with Linux, so what is it that Linux does that > >>>> Xen does not? > >>> They map more than just what is marked for runtime use. > >> IIRC, Linux maps boot services unconditionally (and states in comment > >> that this is not in line with spec). We do not have such mechanism. > >> Could we ease life of our users and add a boot option (e.g. map-efi-bs) > >> which will enforce mapping of BS regions on platforms with buggy EFI/UEFI > >> implementations? We should not penalize owners of such hardware because > >> they are not guilty of these crazy bugs. We should educate firmware devs... > >> Ehh... Please, do not curse at me. I remember discussion about EFI reset > >> stuff which happened here a few days ago. > > > > While, in principle, I would like to take a tough stand against buggy > > firmware, the truth is that firmware is always going to be buggy, and > > many users are going to be in a position where their buggy firmware is > > not going to be fixed by their vendors. Much as I would prefer not to, > > I feel that the only rational course of action to take is to behave like > > Linux in cases like this. > > > > Therefore, I am a begrudgingly +1 "work around EFI firmware bugs", > > despite it being the wrong pragmatic thing to do. > > And I agree that we will need to accept in such workarounds. But > two remarks to whoever is going to implement it: We already have > the efi-rs workaround option - we should deprecate that one, and > have a consolidated efi= one instead, covering the case here too. > Plus the issue here is not just a matter of mapping BS memory, but > also not making it available to the allocator. That in turn may yield > problems with the conversion of the EFI memory map to E820 form, > both because of the number of entries needed, and because that > conversion happens _before_ the normal command line parsing. Twisty maze. However even with my 'debug' patch and mapping the boot services it still fails on this laptop. So I fear there is something more to my woes with Lenovo's EFI firmware implementation. > > Jan > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-27 14:26 ` Konrad Rzeszutek Wilk @ 2015-01-27 16:17 ` Jan Beulich 2015-01-27 18:20 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 27+ messages in thread From: Jan Beulich @ 2015-01-27 16:17 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: Andrew Cooper, Daniel Kiper, xen-devel >>> On 27.01.15 at 15:26, <konrad.wilk@oracle.com> wrote: > On Tue, Jan 27, 2015 at 07:54:30AM +0000, Jan Beulich wrote: >> (re-adding xen-devel) >> >> >>> On 27.01.15 at 01:32, <andrew.cooper3@citrix.com> wrote: >> > On 27/01/2015 00:02, Daniel Kiper wrote: >> >> On Mon, Jan 26, 2015 at 05:00:41PM +0000, Jan Beulich wrote: >> >>>>>> On 26.01.15 at 17:27, <konrad.wilk@oracle.com> wrote: >> >>>> Anyhow I am bit stuck: >> >>>> 1) It works with Linux, so what is it that Linux does that >> >>>> Xen does not? >> >>> They map more than just what is marked for runtime use. >> >> IIRC, Linux maps boot services unconditionally (and states in comment >> >> that this is not in line with spec). We do not have such mechanism. >> >> Could we ease life of our users and add a boot option (e.g. map-efi-bs) >> >> which will enforce mapping of BS regions on platforms with buggy EFI/UEFI >> >> implementations? We should not penalize owners of such hardware because >> >> they are not guilty of these crazy bugs. We should educate firmware devs... >> >> Ehh... Please, do not curse at me. I remember discussion about EFI reset >> >> stuff which happened here a few days ago. >> > >> > While, in principle, I would like to take a tough stand against buggy >> > firmware, the truth is that firmware is always going to be buggy, and >> > many users are going to be in a position where their buggy firmware is >> > not going to be fixed by their vendors. Much as I would prefer not to, >> > I feel that the only rational course of action to take is to behave like >> > Linux in cases like this. >> > >> > Therefore, I am a begrudgingly +1 "work around EFI firmware bugs", >> > despite it being the wrong pragmatic thing to do. >> >> And I agree that we will need to accept in such workarounds. But >> two remarks to whoever is going to implement it: We already have >> the efi-rs workaround option - we should deprecate that one, and >> have a consolidated efi= one instead, covering the case here too. >> Plus the issue here is not just a matter of mapping BS memory, but >> also not making it available to the allocator. That in turn may yield >> problems with the conversion of the EFI memory map to E820 form, >> both because of the number of entries needed, and because that >> conversion happens _before_ the normal command line parsing. > > Twisty maze. > > However even with my 'debug' patch and mapping the boot services > it still fails on this laptop. So I fear there is something more > to my woes with Lenovo's EFI firmware implementation. Again - apart from mapping the range, did you also make sure it didn't get passed to the allocator (and hence couldn't have got overwritten)? Jan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-27 16:17 ` Jan Beulich @ 2015-01-27 18:20 ` Konrad Rzeszutek Wilk 2015-01-28 8:40 ` Jan Beulich 0 siblings, 1 reply; 27+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-01-27 18:20 UTC (permalink / raw) To: Jan Beulich; +Cc: Andrew Cooper, Daniel Kiper, xen-devel [-- Attachment #1: Type: text/plain, Size: 9717 bytes --] On Tue, Jan 27, 2015 at 04:17:05PM +0000, Jan Beulich wrote: > >>> On 27.01.15 at 15:26, <konrad.wilk@oracle.com> wrote: > > On Tue, Jan 27, 2015 at 07:54:30AM +0000, Jan Beulich wrote: > >> (re-adding xen-devel) > >> > >> >>> On 27.01.15 at 01:32, <andrew.cooper3@citrix.com> wrote: > >> > On 27/01/2015 00:02, Daniel Kiper wrote: > >> >> On Mon, Jan 26, 2015 at 05:00:41PM +0000, Jan Beulich wrote: > >> >>>>>> On 26.01.15 at 17:27, <konrad.wilk@oracle.com> wrote: > >> >>>> Anyhow I am bit stuck: > >> >>>> 1) It works with Linux, so what is it that Linux does that > >> >>>> Xen does not? > >> >>> They map more than just what is marked for runtime use. > >> >> IIRC, Linux maps boot services unconditionally (and states in comment > >> >> that this is not in line with spec). We do not have such mechanism. > >> >> Could we ease life of our users and add a boot option (e.g. map-efi-bs) > >> >> which will enforce mapping of BS regions on platforms with buggy EFI/UEFI > >> >> implementations? We should not penalize owners of such hardware because > >> >> they are not guilty of these crazy bugs. We should educate firmware devs... > >> >> Ehh... Please, do not curse at me. I remember discussion about EFI reset > >> >> stuff which happened here a few days ago. > >> > > >> > While, in principle, I would like to take a tough stand against buggy > >> > firmware, the truth is that firmware is always going to be buggy, and > >> > many users are going to be in a position where their buggy firmware is > >> > not going to be fixed by their vendors. Much as I would prefer not to, > >> > I feel that the only rational course of action to take is to behave like > >> > Linux in cases like this. > >> > > >> > Therefore, I am a begrudgingly +1 "work around EFI firmware bugs", > >> > despite it being the wrong pragmatic thing to do. > >> > >> And I agree that we will need to accept in such workarounds. But > >> two remarks to whoever is going to implement it: We already have > >> the efi-rs workaround option - we should deprecate that one, and > >> have a consolidated efi= one instead, covering the case here too. > >> Plus the issue here is not just a matter of mapping BS memory, but > >> also not making it available to the allocator. That in turn may yield > >> problems with the conversion of the EFI memory map to E820 form, > >> both because of the number of entries needed, and because that > >> conversion happens _before_ the normal command line parsing. > > > > Twisty maze. > > > > However even with my 'debug' patch and mapping the boot services > > it still fails on this laptop. So I fear there is something more > > to my woes with Lenovo's EFI firmware implementation. > > Again - apart from mapping the range, did you also make sure it > didn't get passed to the allocator (and hence couldn't have got > overwritten)? Yes, see patch: Also see attached of the code with what Linux sees and what Xen sees (Linux first). I am thinking that the firmware is under the assumption that if SetVirtualAddressMap is not called then you MUST be still before ExitBootServices has been called. Going to verify that by implementing an GetNextVariableName before calling ExitBootServices) diff --git a/xen/Rules.mk b/xen/Rules.mk index b4315a5..6692242 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -7,10 +7,10 @@ verbose ?= y perfc ?= n perfc_arrays ?= n lock_profile ?= n -crash_debug ?= y -frame_pointer ?= y +crash_debug ?= n +frame_pointer ?= n lto ?= n -debug := y +debug := n include $(XEN_ROOT)/Config.mk diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h index 3a3b4fe..c3bdb8d 100644 --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -152,8 +152,6 @@ static void __init efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable, type = E820_RESERVED; break; case EfiConventionalMemory: - case EfiBootServicesCode: - case EfiBootServicesData: if ( !trampoline_phys && desc->PhysicalStart + len <= 0x100000 && len >= cfg.size && desc->PhysicalStart + len > cfg.addr ) cfg.addr = (desc->PhysicalStart + len - cfg.size) & PAGE_MASK; diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index c11b572..e7c939e 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -1159,17 +1221,27 @@ void __init efi_init_memory(void) u64 len = desc->NumberOfPages << EFI_PAGE_SHIFT; unsigned long smfn, emfn; unsigned int prot = PAGE_HYPERVISOR; + unsigned int skip = 1; printk(XENLOG_INFO " %013" PRIx64 "-%013" PRIx64 " type=%u attr=%016" PRIx64 "\n", desc->PhysicalStart, desc->PhysicalStart + len - 1, desc->Type, desc->Attribute); - if ( !efi_rs_enable || !(desc->Attribute & EFI_MEMORY_RUNTIME) ) - { - printk(XENLOG_INFO " .. skipped!\n"); + if ( desc->Attribute & EFI_MEMORY_RUNTIME ) + skip = 0; + + if ( desc->Type == 4 && desc->Attribute != 0 ) + skip = 0; + + if ( desc->Type == 3 && desc->Attribute != 0 ) + skip = 0; + + if ( !efi_rs_enable || skip ) + { + printk(XENLOG_INFO " .. skipped!\n"); continue; - } + } desc->VirtualStart = INVALID_VIRTUAL_ADDRESS; smfn = PFN_DOWN(desc->PhysicalStart); @@ -1246,18 +1318,28 @@ void __init efi_init_memory(void) copy_mapping(0, max_page, ram_range_valid); + printk(XENLOG_INFO "Copying..\n"); /* Insert non-RAM runtime mappings inside the direct map. */ for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size ) { const EFI_MEMORY_DESCRIPTOR *desc = efi_memmap + i; - if ( (desc->Attribute & EFI_MEMORY_RUNTIME) && + if ( ((desc->Attribute & EFI_MEMORY_RUNTIME) || + (desc->Type == 3 && desc->Attribute != 0 ) || + (desc->Type == 4 && desc->Attribute != 0 )) && desc->VirtualStart != INVALID_VIRTUAL_ADDRESS && - desc->VirtualStart != desc->PhysicalStart ) + desc->VirtualStart != desc->PhysicalStart ) { + + printk(XENLOG_INFO " %013" PRIx64 "-%013" PRIx64 + " type=%u attr=%016" PRIx64 "\n", + PFN_DOWN(desc->PhysicalStart), PFN_UP(desc->PhysicalStart + (desc->NumberOfPages << EFI_PAGE_SHIFT)), + desc->Type, desc->Attribute); + copy_mapping(PFN_DOWN(desc->PhysicalStart), PFN_UP(desc->PhysicalStart + (desc->NumberOfPages << EFI_PAGE_SHIFT)), rt_range_valid); + } } /* Insert non-RAM runtime mappings outside of the direct map. */ diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c index 0750436..15401a4 100644 --- a/xen/common/efi/runtime.c +++ b/xen/common/efi/runtime.c @@ -146,6 +146,44 @@ static void _delay(void) } printk("\n"); } +static void _dumpcode(char *code, unsigned long s, unsigned long e) +{ + unsigned long idx, e_idx; + unsigned long cr3; + unsigned int i; + + if ( s > e ) + return; + + idx = s; + + printk("%lx -> %lx\nCode: ", s, e); + do { + e_idx = idx + 4095; + if ( e_idx > e ) + e_idx = e; + + process_pending_softirqs(); + + memset(code, 0, 4096); + + cr3 = efi_rs_enter(); + memcpy(code, (void *)idx, e_idx - idx); + efi_rs_leave(cr3); + + for ( i = 0; i < e_idx - idx ;i++) + { + if ( i & 0xFF ) + process_pending_softirqs(); + printk(" %02x", (unsigned short)code[i] & 0xFF); + } + printk("\n"); + idx = e_idx + 1; + } while ( idx < e ); + + printk("\n"); + _delay(); +} long efi_debug(void) { @@ -162,12 +200,13 @@ long efi_debug(void) unsigned int rev; unsigned long getnext, get; char *code; + unsigned long val[13]; if ( !cr3 ) return -EOPNOTSUPP; efi_rs_leave(cr3); - code = xzalloc_bytes(size); + code = xzalloc_bytes(4096); if ( !code ) return -ENOMEM; @@ -193,18 +232,41 @@ long efi_debug(void) cr3 = efi_rs_enter(); getnext = (unsigned long)efi_rs->GetNextVariableName; - memcpy(code, efi_rs->GetNextVariableName, 1024); - get = (unsigned long)efi_rs->GetVariable; + get = (unsigned long)efi_rs; efi_rs_leave(cr3); - printk(", GetNextVariableName: %lx, GetVariable: %lx\n", getnext, get); - printk(" Code: "); - for ( i = 0; i < 1024;i++) - printk(" %02x", (unsigned short)code[i] & 0xFF); - printk("\n"); + printk(", GetNextVariableName: %lx, efi_rs: %lx\n", getnext, get); + + val[0] = 0xcfdba230; /* Saw it somewhere Boot Services?? */ + val[1] = 0xcfdba270; + val[2] = val[0] + 0x18; + val[3] = val[1] + 0x18; + val[4] = 0xcfdc9cc0; + val[5] = getnext + + 0x11bc; /* 3f: */ + val[6] = getnext + 0x11fc; + val[7] = getnext + 0x11e4; + val[8] = getnext + 0x1154; + val[9] = getnext + 0x116c; + val[10] = getnext + 0x11d4; + val[11] = getnext + 0x1154; + val[12] = getnext + 0x116c; + + for ( i = 0; i < 13; i++) + { + printk("val[%d]:\n", i); + _dumpcode(code, val[i], val[i] + 8); + } +#if 0 + _dumpcode(code, get, get+4096); + _delay(); + _dumpcode(code, 0x00000d6929000, 0x00000d6a4ffff); _delay(); + _dumpcode(code, 0x00000cfdba000,0x00000cfdcffff); + _delay(); +#endif + _dumpcode(code, 0, 512); idx = 1; do { printk("%4d:", idx++); > > Jan > [-- Attachment #2: print.txt --] [-- Type: text/plain, Size: 7204 bytes --] 0: 48 89 5c 24 08 mov %rbx,0x8(%rsp) 5: 48 89 6c 24 10 mov %rbp,0x10(%rsp) a: 48 89 74 24 18 mov %rsi,0x18(%rsp) f: 57 push %rdi 10: 41 54 push %r12 12: 41 55 push %r13 14: 48 83 ec 20 sub $0x20,%rsp 18: 45 33 ed xor %r13d,%r13d 1b: 48 85 c9 test %rcx,%rcx 1e: 4d 8b e0 mov %r8,%r12 21: 48 8b fa mov %rdx,%rdi 24: 48 8b e9 mov %rcx,%rbp 27: 0f 84 09 01 00 00 je 0x136 2d: 48 85 d2 test %rdx,%rdx 30: 0f 84 00 01 00 00 je 0x136 36: 4d 85 c0 test %r8,%r8 39: 0f 84 f7 00 00 00 je 0x136 3f: 48 8b 05 76 11 00 00 mov 0x1176(%rip),%rax # 0x11bc [20 53 c3 fa fe ff ff ff][20 53 a3 d6 00 00 00 00 46: 48 8d 15 af 11 00 00 lea 0x11af(%rip),%rdx # 0x11fc [00 54 f3 41 60 06 1c 8][00 6d 15 d8 d6 db 40 8d 4d: 48 8b c8 mov %rax,%rcx 50: ff 50 20 callq *0x20(%rax) 53: 80 3d a2 11 00 00 01 cmpb $0x1,0x11a2(%rip) # 0x11fc [00 54 f3 41 60 06 1c 8][00 6d 15 d8 d6 db 40 8d] 5a: 75 1b jne 0x77 5c: 48 8b 05 81 11 00 00 mov 0x1181(%rip),%rax # 0x11e4 [80 62 2b db 00 00 00 00][80 62 2b db 00 00 00 0] 63: 4d 8b c4 mov %r12,%r8 66: 48 8b d7 mov %rdi,%rdx 69: 48 8b cd mov %rbp,%rcx 6c: ff 50 08 callq *0x8(%rax) 6f: 48 8b d8 mov %rax,%rbx 72: e9 ba 00 00 00 jmpq 0x131 77: 48 8b cf mov %rdi,%rcx 7a: e8 bd 0f 00 00 callq 0x103c 7f: 48 3d 00 01 00 00 cmp $0x100,%rax 85: 0f 87 ab 00 00 00 ja 0x136 8b: 44 38 2d c2 10 00 00 cmp %r13b,0x10c2(%rip) # 0x115 [01 01 00 00 00 00 00 00][00 01 00 00 00 00 00 00 92: 75 12 jne 0xa6 94: 48 8b 05 d1 10 00 00 mov 0x10d1(%rip),%rax # 0x116c [70 a2 db cf 00 00 00 00][70 a2 db cf 00 00 00 00 9b: b9 1f 00 00 00 mov $0x1f,%ecx a0: ff 50 18 callq *0x18(%rax) a3: 4c 8b e8 mov %rax,%r13 a6: 48 8b 35 27 11 00 00 mov 0x1127(%rip),%rsi # 0x11d4 [10 d0 87 fa fe ff ff ff][10 d0 47 da 00 00 00 00 ad: 48 8b d7 mov %rdi,%rdx b0: c6 06 5a movb $0x5a,(%rsi) b3: c6 46 01 6b movb $0x6b,0x1(%rsi) b7: 48 8b 4d 00 mov 0x0(%rbp),%rcx bb: 48 89 4e 18 mov %rcx,0x18(%rsi) bf: 48 8d 4e 20 lea 0x20(%rsi),%rcx c3: e8 58 0f 00 00 callq 0x1020 c8: 48 8d 8e 20 02 00 00 lea 0x220(%rsi),%rcx cf: 41 b8 10 00 00 00 mov $0x10,%r8d d5: 49 8b d4 mov %r12,%rdx d8: e8 ff 0e 00 00 callq 0xfdc dd: e8 3a fb ff ff callq 0xfffffffffffffc1c e2: 44 8a 1e mov (%rsi),%r11b e5: 41 80 fb 5a cmp $0x5a,%r11b e9: 74 bb je 0xa6 eb: 48 8b 5e 08 mov 0x8(%rsi),%rbx ef: 48 8b 46 18 mov 0x18(%rsi),%rax f3: 48 85 db test %rbx,%rbx f6: 48 89 45 00 mov %rax,0x0(%rbp) fa: 75 1f jne 0x11b fc: 48 8d 56 20 lea 0x20(%rsi),%rdx 100: 48 8b cf mov %rdi,%rcx 103: e8 18 0f 00 00 callq 0x1020 108: 48 8d 96 20 02 00 00 lea 0x220(%rsi),%rdx 10f: 44 8d 43 10 lea 0x10(%rbx),%r8d 113: 49 8b cc mov %r12,%rcx 116: e8 c1 0e 00 00 callq 0xfdc 11b: 80 3d 32 10 00 00 00 cmpb $0x0,0x1032(%rip) # 0x1154 [70 a2 db cf 00 00 00 00][00 01 00 00 00 00 00 00] 122: 75 0d jne 0x131 124: 48 8b 05 41 10 00 00 mov 0x1041(%rip),%rax # 0x116c [70 a2 db cf 00 00 00 00][70 a2 db cf 00 00 00 00] 12b: 49 8b cd mov %r13,%rcx 12e: ff 50 20 callq *0x20(%rax) 131: 48 8b c3 mov %rbx,%rax 134: eb 0a jmp 0x140 136: 48 b8 02 00 00 00 00 movabs $0x8000000000000002,%rax 13d: 00 00 80 140: 48 8b 5c 24 40 mov 0x40(%rsp),%rbx 145: 48 8b 6c 24 48 mov 0x48(%rsp),%rbp 14a: 48 8b 74 24 50 mov 0x50(%rsp),%rsi 14f: 48 83 c4 20 add $0x20,%rsp 153: 41 5d pop %r13 155: 41 5c pop %r12 157: 5f pop %rdi 158: c3 retq 159: cc int3 15a: cc int3 15b: cc int3 (XEN) 1:----[ Xen-4.6-unstable x86_64 debug=n Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e008:[<0000000000000007>] 0000000000000007 (XEN) RFLAGS: 0000000000010202 CONTEXT: hypervisor (XEN) rax: 00000000cfdba270 rbx: ffff830214cfea00 rcx: 000000000000001f (XEN) rdx: 00000000d6995ed0 rsi: 0000000000150670 rdi: ffff830214cfe580 (XEN) rbp: ffff82d080457d80 rsp: ffff82d080457cf0 r8: ffff82d080457d88 (XEN) r9: 0000000000008000 r10: ffff82d080457bfc r11: 00000000db002700 (XEN) r12: ffff82d080457d88 r13: 0000000000000000 r14: 0000000000000001 (XEN) r15: 00000000d1079000 cr0: 0000000080050033 cr4: 00000000001506f0 (XEN) cr3: 0000000216b3b000 cr2: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Xen stack trace from rsp=ffff82d080457cf0: (XEN) 0000000068f00002 00000000d6994d77 ffff82d080498b30 0000000000000206 (XEN) 00000000d1079000 ffff830214cfe580 00000000d6995e40 ffff82d080457d90 (XEN) 0000000216b3b000 ffff82d080229e16 ffff830214cfea00 ffff830214cfe580 (XEN) 0000000000150670 ffff82d080229de6 000000000000000a ffff82d080457d88 (XEN) ffff82d080457d80 ffff830214cf3000 0000000000000400 0000000000000246 (XEN) ffff82d080457da0 00000000cfdba230 00000000cfdba270 00000000cfdba248 (XEN) 00000000cfdba288 00000000cfdc9cc0 00000000d6995e90 00000000d6995ed0 (XEN) 00000000d6995eb8 00000000d6995e28 00000000d6995e40 00000000d6995ea8 (XEN) 00000000d6995e28 00000000d6995e40 0000000000000003 ffff830216b314f0 (XEN) 0000000000000002 0000000000000008 0000000000000003 ffff8300d124b040 (XEN) ffff82d080269d80 ffff82d0804259b6 ffff8300d124b040 ffff8300d124afe0 (XEN) 00007d2f00000002 ffff8300d123ac25 00000000012b0000 000000021ab35000 (XEN) 0000000000000000 00000000ffffffff 000000000021e600 0000000000000000 (XEN) 00000000d124afe0 ffffffd080499780 0000000000499780 00000000012b0fff (XEN) 0000000000100000 0058bf9000000000 0000000800000000 000000010000006e (XEN) 0000000000000003 00000000000002f8 0000000000000000 00000000d123a280 (XEN) 00000000d0793408 00000000d0eff388 0000000000057000 00000000fed20000 (XEN) 0000000000002960 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<0000000000000007>] 0000000000000007 (XEN) [<ffff82d080229e16>] efi_debug+0x246/0x3b0 (XEN) [<ffff82d080229de6>] efi_debug+0x216/0x3b0 (XEN) [<ffff82d0804259b6>] __start_xen+0x25b6/0x3bc0 [-- Attachment #3: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-27 18:20 ` Konrad Rzeszutek Wilk @ 2015-01-28 8:40 ` Jan Beulich 2015-01-28 16:03 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 27+ messages in thread From: Jan Beulich @ 2015-01-28 8:40 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: Andrew Cooper, Daniel Kiper, xen-devel >>> On 27.01.15 at 19:20, <konrad.wilk@oracle.com> wrote: > On Tue, Jan 27, 2015 at 04:17:05PM +0000, Jan Beulich wrote: >> Again - apart from mapping the range, did you also make sure it >> didn't get passed to the allocator (and hence couldn't have got >> overwritten)? > > Yes, see patch: Oh, sorry, I must have not looked closely enough. > Also see attached of the code with what Linux sees and what Xen sees > (Linux first). Indeed this 8b: 44 38 2d c2 10 00 00 cmp %r13b,0x10c2(%rip) # 0x115 [01 01 00 00 00 00 00 00][00 01 00 00 00 00 00 00 92: 75 12 jne 0xa6 causes the code in question to be skipped under Linux. > I am thinking that the firmware is under the assumption > that if SetVirtualAddressMap is not called then you MUST be still > before ExitBootServices has been called. Going to verify that by > implementing an GetNextVariableName before calling ExitBootServices) Not sure how exactly you envision to do this, but I'm having a hard time seeing how this would prove anything, in particular because calling runtime services functions prior to exiting boot services must be possible anyway. And iirc you had already tried calling the function prior to doing much else (namely, prior to loading Dom0), and it still crashed? Did you investigate when the memory type of that region changes (in an earlier mail you said dmem from the EFI shell reported it as Boot Services, albeit it's not fully clear what that tagging is supposed to be telling us)? Jan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-28 8:40 ` Jan Beulich @ 2015-01-28 16:03 ` Konrad Rzeszutek Wilk 2015-01-28 16:12 ` Konrad Rzeszutek Wilk 2015-01-28 16:17 ` Daniel Kiper 0 siblings, 2 replies; 27+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-01-28 16:03 UTC (permalink / raw) To: Jan Beulich; +Cc: Andrew Cooper, Daniel Kiper, xen-devel On Wed, Jan 28, 2015 at 08:40:44AM +0000, Jan Beulich wrote: > >>> On 27.01.15 at 19:20, <konrad.wilk@oracle.com> wrote: > > On Tue, Jan 27, 2015 at 04:17:05PM +0000, Jan Beulich wrote: > >> Again - apart from mapping the range, did you also make sure it > >> didn't get passed to the allocator (and hence couldn't have got > >> overwritten)? > > > > Yes, see patch: > > Oh, sorry, I must have not looked closely enough. > > > Also see attached of the code with what Linux sees and what Xen sees > > (Linux first). > > Indeed this > > 8b: 44 38 2d c2 10 00 00 cmp %r13b,0x10c2(%rip) # 0x115 [01 01 00 00 00 00 00 00][00 01 00 00 00 00 00 00 > 92: 75 12 jne 0xa6 > > causes the code in question to be skipped under Linux. > > > I am thinking that the firmware is under the assumption > > that if SetVirtualAddressMap is not called then you MUST be still > > before ExitBootServices has been called. Going to verify that by > > implementing an GetNextVariableName before calling ExitBootServices) > > Not sure how exactly you envision to do this, but I'm having a hard > time seeing how this would prove anything, in particular because > calling runtime services functions prior to exiting boot services must > be possible anyway. And it works - one of the patches implements an routine to call the dreaded function before ExitBootServices and it works nicely (ie - I see: Xen 4.6-unstable (c/s Tue Jan 27 14:05:36 2015 -0500 git:332c049-dirty) EFI loader Using configuration file 'xen.cfg' vmlinuz-3.19.0-rc4+: 0x00000000cf81a000-0x00000000cfda5f90 initramfs-3.19.0-rc4+.img: 0x00000000cb522000-0x00000000cd7b04d3 GetNextVariableName: 0x8be4df610x93ca0x11d20xaa0xd0x00xe00x980x30x2b0x8c:SimpleBootFlag 0x0 0x5e724c0c0x5c030x45430xbc0xb60xc10xe20x3d0xe20x410x36:TpmSaveState 0x0 0x6403753b0xabde0x4da20xaa0x110x690x830xef0x2a0x7a0x69:TpmAcpiData 0x0 0x8be4df610x93ca0x11d20xaa0xd0x00xe00x980x30x2b0x8c:SetupMode 0x0 0x8be4df610x93ca0x11d20xaa0xd0x00xe00x980x30x2b0x8c:SecureBoot 0x0 0xe5bbf7be0x24170x499b0x970xdb0x390xf40x890x630x910xbc:BuildDate 0x0 Could not get next variable It is just that making that call after ExitBootServices does not work. But on Linux the extra mix is that we also call 'SetVirtualAddressMap' which we do not do. > > And iirc you had already tried calling the function prior to doing much > else (namely, prior to loading Dom0), and it still crashed? Did you Yes, it did crash. That is - we call it _after_ calling ExitBootServices. > investigate when the memory type of that region changes (in an > earlier mail you said dmem from the EFI shell reported it as Boot > Services, albeit it's not fully clear what that tagging is supposed to > be telling us)? It did not help. Having the mapping of BootServicesData&Code did not help with the problem. However having disabled the call to ExitBootServices the mapping of BootServicesData&Code did help - as we were able to make the proper calls. In short, I think the firmware has a bug where it makes the assumption that if SetVirtualAddressMap then BootServices should _not_ be used - otherwise it will use it. I am not really sure of what the work-around should be in Xen except making SetVirtualAddressMap work.. > > Jan > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-28 16:03 ` Konrad Rzeszutek Wilk @ 2015-01-28 16:12 ` Konrad Rzeszutek Wilk 2015-01-28 16:17 ` Daniel Kiper 1 sibling, 0 replies; 27+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-01-28 16:12 UTC (permalink / raw) To: Jan Beulich, Marcos Matsunaga; +Cc: Andrew Cooper, Daniel Kiper, xen-devel [-- Attachment #1: Type: text/plain, Size: 3546 bytes --] On Wed, Jan 28, 2015 at 11:03:19AM -0500, Konrad Rzeszutek Wilk wrote: > On Wed, Jan 28, 2015 at 08:40:44AM +0000, Jan Beulich wrote: > > >>> On 27.01.15 at 19:20, <konrad.wilk@oracle.com> wrote: > > > On Tue, Jan 27, 2015 at 04:17:05PM +0000, Jan Beulich wrote: > > >> Again - apart from mapping the range, did you also make sure it > > >> didn't get passed to the allocator (and hence couldn't have got > > >> overwritten)? > > > > > > Yes, see patch: > > > > Oh, sorry, I must have not looked closely enough. > > > > > Also see attached of the code with what Linux sees and what Xen sees > > > (Linux first). > > > > Indeed this > > > > 8b: 44 38 2d c2 10 00 00 cmp %r13b,0x10c2(%rip) # 0x115 [01 01 00 00 00 00 00 00][00 01 00 00 00 00 00 00 > > 92: 75 12 jne 0xa6 > > > > causes the code in question to be skipped under Linux. > > > > > I am thinking that the firmware is under the assumption > > > that if SetVirtualAddressMap is not called then you MUST be still > > > before ExitBootServices has been called. Going to verify that by > > > implementing an GetNextVariableName before calling ExitBootServices) > > > > Not sure how exactly you envision to do this, but I'm having a hard > > time seeing how this would prove anything, in particular because > > calling runtime services functions prior to exiting boot services must > > be possible anyway. > > And it works - one of the patches implements an routine to call the > dreaded function before ExitBootServices and it works nicely (ie - I > see: > > Xen 4.6-unstable (c/s Tue Jan 27 14:05:36 2015 -0500 git:332c049-dirty) EFI loader > Using configuration file 'xen.cfg' > vmlinuz-3.19.0-rc4+: 0x00000000cf81a000-0x00000000cfda5f90 > initramfs-3.19.0-rc4+.img: 0x00000000cb522000-0x00000000cd7b04d3 > GetNextVariableName: > 0x8be4df610x93ca0x11d20xaa0xd0x00xe00x980x30x2b0x8c:SimpleBootFlag 0x0 > 0x5e724c0c0x5c030x45430xbc0xb60xc10xe20x3d0xe20x410x36:TpmSaveState 0x0 > 0x6403753b0xabde0x4da20xaa0x110x690x830xef0x2a0x7a0x69:TpmAcpiData 0x0 > 0x8be4df610x93ca0x11d20xaa0xd0x00xe00x980x30x2b0x8c:SetupMode 0x0 > 0x8be4df610x93ca0x11d20xaa0xd0x00xe00x980x30x2b0x8c:SecureBoot 0x0 > 0xe5bbf7be0x24170x499b0x970xdb0x390xf40x890x630x910xbc:BuildDate 0x0 > Could not get next variable > > > It is just that making that call after ExitBootServices does not > work. But on Linux the extra mix is that we also call 'SetVirtualAddressMap' > which we do not do. > > > > And iirc you had already tried calling the function prior to doing much > > else (namely, prior to loading Dom0), and it still crashed? Did you > > Yes, it did crash. That is - we call it _after_ calling ExitBootServices. > > > investigate when the memory type of that region changes (in an > > earlier mail you said dmem from the EFI shell reported it as Boot > > Services, albeit it's not fully clear what that tagging is supposed to > > be telling us)? > > It did not help. Having the mapping of BootServicesData&Code did not > help with the problem. However having disabled the call to > ExitBootServices the mapping of BootServicesData&Code did help - as we > were able to make the proper calls. > > In short, I think the firmware has a bug where it makes the assumption > that if SetVirtualAddressMap then BootServices should _not_ be used > - otherwise it will use it. > > I am not really sure of what the work-around should be in Xen except > making SetVirtualAddressMap work.. And the patches I sent were missing one. Here are all of them. > > > > Jan > > [-- Attachment #2: 0001-EFI-Call-GetNextVariableName-during-normal-init.patch --] [-- Type: text/plain, Size: 6044 bytes --] >From 60f7b43349c2ed961459a1902165a41799d58c90 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Sun, 25 Jan 2015 16:50:58 -0500 Subject: [PATCH 1/5] EFI: Call GetNextVariableName during normal init. Along with some extra debugging code to help diagnose the issue. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- xen/arch/x86/efi/stub.c | 1 + xen/arch/x86/setup.c | 7 +++ xen/common/efi/boot.c | 3 + xen/common/efi/runtime.c | 148 ++++++++++++++++++++++++++++++++++++++++++++++- xen/include/xen/efi.h | 1 + 5 files changed, 159 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c index b8f49f8..cefd18d 100644 --- a/xen/arch/x86/efi/stub.c +++ b/xen/arch/x86/efi/stub.c @@ -21,6 +21,7 @@ unsigned long efi_get_time(void) return 0; } +long efi_debug(void) { return -ENOSYS; } void efi_halt_system(void) { } void efi_reset_system(bool_t warm) { } diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 39f2a4d..f82e3c0 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1316,6 +1316,13 @@ void __init noreturn __start_xen(unsigned long mbi_p) console_init_postirq(); + if ( efi_enabled ) + { + long ret = efi_debug(); + if ( ret ) + printk("efi_debug return code: %lx\n", ret); + } + system_state = SYS_STATE_smp_boot; do_presmp_initcalls(); diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index ac6881e..c04e0a2 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -1163,7 +1163,10 @@ void __init efi_init_memory(void) desc->Type, desc->Attribute); if ( !efi_rs_enable || !(desc->Attribute & EFI_MEMORY_RUNTIME) ) + { + printk(XENLOG_INFO " .. skipped!\n"); continue; + } desc->VirtualStart = INVALID_VIRTUAL_ADDRESS; diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c index c840e08..ef6b1df 100644 --- a/xen/common/efi/runtime.c +++ b/xen/common/efi/runtime.c @@ -5,7 +5,8 @@ #include <xen/guest_access.h> #include <xen/irq.h> #include <xen/time.h> - +#include <xen/delay.h> +#include <xen/softirq.h> DEFINE_XEN_GUEST_HANDLE(CHAR16); #ifndef COMPAT @@ -128,6 +129,151 @@ unsigned long efi_get_time(void) time.Hour, time.Minute, time.Second); } +static void _delay(void) +{ + unsigned int i; + + printk("Delay of 3 seconds: "); + for (i = 0; i < 3; i++) + { + unsigned int j; + printk("..%d", (3 - i)); + for (j = 0; j < 100; j++) + { + process_pending_softirqs(); + mdelay(10); + } + } + printk("\n"); +} +#define DUMP_LEN 1024 +static void __init _dumpcode(unsigned long s, unsigned long e) +{ + unsigned long idx, e_idx; + unsigned long cr3; + unsigned int i; + char *code; + + if ( s > e ) + return; + + idx = s; + + code = xzalloc_bytes(DUMP_LEN); + if ( !code ) + return; + + printk("%lx -> %lx\nCode:", s, e); + do { + e_idx = idx + DUMP_LEN - 1; + if ( e_idx > e ) + e_idx = e; + + process_pending_softirqs(); + + memset(code, 0, DUMP_LEN); + + cr3 = efi_rs_enter(); + memcpy(code, (void *)idx, e_idx - idx); + efi_rs_leave(cr3); + + for ( i = 0; i < e_idx - idx ;i++) + { + if ( i & 0xFF ) + process_pending_softirqs(); + printk(" %02x", (unsigned short)code[i] & 0xFF); + } + printk("\n"); + idx = e_idx + 1; + } while ( idx < e ); + xfree(code); + printk("\n"); + _delay(); +} + +long __init efi_debug(void) +{ + unsigned long cr3 = efi_rs_enter(); + union { + CHAR16 *str; + unsigned char *raw; + } name; + char *p; + UINTN size = 1024; + struct xenpf_efi_guid guid; + EFI_STATUS status; + unsigned int i, idx; + unsigned int rev; + unsigned long get; + + if ( !cr3 ) + return -EOPNOTSUPP; + efi_rs_leave(cr3); + + name.raw = xzalloc_bytes(size); + if ( !name.raw ) + return -ENOMEM; + + p = xzalloc_bytes(size); + if ( !p ) + { + xfree(name.raw); + return -ENOMEM; + } + + printk("EFI v"); + + cr3 = efi_rs_enter(); + rev = efi_rs->Hdr.Revision; + efi_rs_leave(cr3); + + printk("%d.%d", rev >> 16, rev & 0xF); + + cr3 = efi_rs_enter(); + get = (unsigned long)efi_rs->GetNextVariableName; + efi_rs_leave(cr3); + + printk(", GetNextVariableName: %lx\n", get); + + _dumpcode(get, get+1024); + + idx = 1; + do { + printk("%4d:", idx++); + + cr3 = efi_rs_enter(); + if ( !cr3 ) + break; + + size = 1024; + status = efi_rs->GetNextVariableName(&size, name.str, (void *)&guid); + efi_rs_leave(cr3); + + if ( !EFI_ERROR(status) ) + { + unsigned int j; + + printk("%04x-%02x-%02x-", guid.data1, guid.data2, guid.data3); + for ( i = 0; i < 8; i++) + printk("-%02x", guid.data4[i]); + + for ( i = 0, j = 0; i < size && j < size / sizeof(CHAR16); i++, j++) + p[j] = name.str[i] & 0xFF; + + p[j] = '\0'; + printk(": %s [%lx]\n", p, status); + } else + printk("EFI_ERROR: %lx\n", status); + } while ( !EFI_ERROR(status) ); + + xfree(p); + xfree(name.raw); + + if ( EFI_ERROR(EFI_NOT_FOUND) ) + return 0; + + return status; +} void efi_halt_system(void) { EFI_STATUS status; diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h index 5e02724..4e9ffbf 100644 --- a/xen/include/xen/efi.h +++ b/xen/include/xen/efi.h @@ -30,6 +30,7 @@ struct compat_pf_efi_runtime_call; void efi_init_memory(void); paddr_t efi_rs_page_table(void); unsigned long efi_get_time(void); +long efi_debug(void); void efi_halt_system(void); void efi_reset_system(bool_t warm); #ifndef COMPAT -- 2.1.0 [-- Attachment #3: 0002-EFI-Map-also-BootServicesData-and-BootServicesCode.patch --] [-- Type: text/plain, Size: 3574 bytes --] >From 49aab3d6e623c907164475403ba495ede442e6e5 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Tue, 27 Jan 2015 15:32:10 -0500 Subject: [PATCH 2/5] EFI: Map also BootServicesData and BootServicesCode Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- xen/arch/x86/efi/efi-boot.h | 2 -- xen/common/efi/boot.c | 27 ++++++++++++++++++++++++--- 2 files changed, 24 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h index 3a3b4fe..c3bdb8d 100644 --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -152,8 +152,6 @@ static void __init efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable, type = E820_RESERVED; break; case EfiConventionalMemory: - case EfiBootServicesCode: - case EfiBootServicesData: if ( !trampoline_phys && desc->PhysicalStart + len <= 0x100000 && len >= cfg.size && desc->PhysicalStart + len > cfg.addr ) cfg.addr = (desc->PhysicalStart + len - cfg.size) & PAGE_MASK; diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index c04e0a2..b0bbc4b 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -1156,13 +1156,23 @@ void __init efi_init_memory(void) u64 len = desc->NumberOfPages << EFI_PAGE_SHIFT; unsigned long smfn, emfn; unsigned int prot = PAGE_HYPERVISOR; + unsigned int skip = 1; printk(XENLOG_INFO " %013" PRIx64 "-%013" PRIx64 " type=%u attr=%016" PRIx64 "\n", desc->PhysicalStart, desc->PhysicalStart + len - 1, desc->Type, desc->Attribute); - if ( !efi_rs_enable || !(desc->Attribute & EFI_MEMORY_RUNTIME) ) + if ( desc->Attribute & EFI_MEMORY_RUNTIME ) + skip = 0; + + if ( desc->Type == 4 && desc->Attribute != 0 ) + skip = 0; + + if ( desc->Type == 3 && desc->Attribute != 0 ) + skip = 0; + + if ( !efi_rs_enable || skip ) { printk(XENLOG_INFO " .. skipped!\n"); continue; @@ -1246,18 +1256,29 @@ void __init efi_init_memory(void) copy_mapping(0, max_page, ram_range_valid); + printk(XENLOG_INFO "Copying..\n"); /* Insert non-RAM runtime mappings inside the direct map. */ for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size ) { const EFI_MEMORY_DESCRIPTOR *desc = efi_memmap + i; - if ( (desc->Attribute & EFI_MEMORY_RUNTIME) && + if ( ((desc->Attribute & EFI_MEMORY_RUNTIME) || + (desc->Type == 3 && desc->Attribute != 0 ) || + (desc->Type == 4 && desc->Attribute != 0 )) && desc->VirtualStart != INVALID_VIRTUAL_ADDRESS && - desc->VirtualStart != desc->PhysicalStart ) + desc->VirtualStart != desc->PhysicalStart ) { + + printk(XENLOG_INFO " %013" PRIx64 "-%013" PRIx64 + " type=%u attr=%016" PRIx64 "\n", + PFN_DOWN(desc->PhysicalStart), + PFN_UP(desc->PhysicalStart + (desc->NumberOfPages << EFI_PAGE_SHIFT)), + desc->Type, desc->Attribute); + copy_mapping(PFN_DOWN(desc->PhysicalStart), PFN_UP(desc->PhysicalStart + (desc->NumberOfPages << EFI_PAGE_SHIFT)), rt_range_valid); + } } /* Insert non-RAM runtime mappings outside of the direct map. */ -- 2.1.0 [-- Attachment #4: 0003-EFI-early-Implement-GetNextVariableName-and-query-an.patch --] [-- Type: text/plain, Size: 4581 bytes --] >From ffb09e4938021ed47bc7097585dd19a10f2e09de Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Tue, 27 Jan 2015 14:04:30 -0500 Subject: [PATCH 3/5] EFI/early: Implement GetNextVariableName and /query and /noexitboot parameters In the early EFI boot we will enumerate up to five EFI variables to make sure it works. The /query will just enumerate them and then quit. Helps in troubleshooting and redirecting the output to a file (xen.efi /query > q). The /noexitboot will inhibit Xen from calling ExitBootServices. This allows on Lenovo ThinkPad x230 to use GetNextVariableName in 1-1 mapping mode. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- xen/common/efi/boot.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 82 insertions(+), 1 deletion(-) diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index b0bbc4b..4ee8f68 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -673,6 +673,74 @@ static void __init setup_efi_pci(void) efi_bs->FreePool(handles); } +static int __init efi_getnextvariable(bool_t query_only) +{ + EFI_GUID guid; + UINTN i, size, idx; + CHAR16 *name; + EFI_STATUS status; + + + status = efi_bs->AllocatePool(EfiLoaderData, 1024, (void *)&name); + if ( EFI_ERROR(status) ) + return status; + + guid.Data1 = 0; + guid.Data2 = 0; + guid.Data3 = 0; + for ( i = 0; i < 8; i++ ) + guid.Data4[i] = 0; + + for ( i = 0 ; i < 1024 / sizeof (CHAR16); i++ ) + name[i] = 0; + + PrintStr(L"GetNextVariableName: "); + PrintStr(name); + PrintStr(newline); + idx = 0; + do { + size = 1024; + efi_rs->GetNextVariableName(&size, name, &guid); + if ( EFI_ERROR(status) ) + { + if ( query_only ) + { + efi_bs->FreePool(name); + PrintErrMesg(L"Failed to GetNextVariableName", status); + } + else + { + PrintStr(L"Warning: GetNextVariableName: "); + DisplayUint(status, 0); + PrintStr(newline); + } + } + else + { + DisplayUint(guid.Data1, 4); + DisplayUint(guid.Data2, 2); + DisplayUint(guid.Data3, 2); + for ( i = 0; i < 8; i++ ) + DisplayUint(guid.Data4[i], 1); + + PrintStr(L":"); + PrintStr(name); + PrintStr(L" "); + DisplayUint(status, 0); + PrintStr(newline); + } + } while ( !EFI_ERROR(status) && idx++ < 5 ); + + efi_bs->FreePool(name); + + if ( query_only ) + return -EINVAL; + + if ( EFI_ERROR(EFI_NOT_FOUND) ) + return 0; + + return status; +} static int __init __maybe_unused set_color(u32 mask, int bpp, u8 *pos, u8 *sz) { if ( bpp < 0 ) @@ -705,8 +773,10 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info; union string section = { NULL }, name; bool_t base_video = 0, retry; + bool_t query_only = 0; char *option_str; bool_t use_cfg_file; + bool_t exit_boot_services = 0; efi_ih = ImageHandle; efi_bs = SystemTable->BootServices; @@ -751,6 +821,10 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) { if ( wstrcmp(ptr + 1, L"basevideo") == 0 ) base_video = 1; + else if ( wstrcmp(ptr + 1, L"query") == 0 ) + query_only = 1; + else if ( wstrcmp(ptr + 1, L"noexitboot") == 0 ) + exit_boot_services = 0; else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 ) cfg_file_name = ptr + 5; else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 ) @@ -1031,6 +1105,9 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) PrintStr(newline); } + if ( efi_getnextvariable(query_only) ) + blexit(L"Could not get next variable"); + efi_arch_memory_setup(); if ( gop ) @@ -1064,7 +1141,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) efi_arch_pre_exit_boot(); - status = efi_bs->ExitBootServices(ImageHandle, map_key); + if ( exit_boot_services ) + status = efi_bs->ExitBootServices(ImageHandle, map_key); + else + status = 0; + if ( status != EFI_INVALID_PARAMETER || retry ) break; } -- 2.1.0 [-- Attachment #5: 0004-EFI-early-Swap-noexitboot-to-exitboot-and-by-default.patch --] [-- Type: text/plain, Size: 1801 bytes --] >From 76bee287621d22b2c9082eae6eacfea2446722c9 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Tue, 27 Jan 2015 15:35:35 -0500 Subject: [PATCH 4/5] EFI/early: Swap noexitboot to exitboot and by default don't call ExitBootServices. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- xen/common/efi/boot.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index 4ee8f68..d9aabd3 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -823,8 +823,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) base_video = 1; else if ( wstrcmp(ptr + 1, L"query") == 0 ) query_only = 1; - else if ( wstrcmp(ptr + 1, L"noexitboot") == 0 ) - exit_boot_services = 0; + else if ( wstrcmp(ptr + 1, L"exitboot") == 0 ) + exit_boot_services = 1; else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 ) cfg_file_name = ptr + 5; else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 ) @@ -834,6 +834,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) { PrintStr(L"Xen EFI Loader options:\r\n"); PrintStr(L"-basevideo retain current video mode\r\n"); + PrintStr(L"-exitboot call ExitBootServices\r\n"); + PrintStr(L"-query call GetNextVariableName for up to five times\r\n"); PrintStr(L"-cfg=<file> specify configuration file\r\n"); PrintStr(L"-help, -? display this help\r\n"); blexit(NULL); -- 2.1.0 [-- Attachment #6: 0005-EFI-Dump-0xcfda270-and-the-other-address.patch --] [-- Type: text/plain, Size: 931 bytes --] >From 9f7469cd3b8a89594b16f2e39886948987bfa2ae Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Tue, 27 Jan 2015 16:09:51 -0500 Subject: [PATCH 5/5] EFI: Dump 0xcfda270 and the other address Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- xen/common/efi/runtime.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c index ef6b1df..79e8072 100644 --- a/xen/common/efi/runtime.c +++ b/xen/common/efi/runtime.c @@ -236,7 +236,12 @@ long __init efi_debug(void) printk(", GetNextVariableName: %lx\n", get); _dumpcode(get, get+1024); - + get = 0xcfdba270; + _dumpcode(get, get+8); + _dumpcode(get + 0x18, get + 0x18 + 8); + _dumpcode(get + 0x20, get + 0x20 + 8); + get = 0xcfdc3048; + _dumpcode(get, get+1024); idx = 1; do { printk("%4d:", idx++); -- 2.1.0 [-- Attachment #7: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-28 16:03 ` Konrad Rzeszutek Wilk 2015-01-28 16:12 ` Konrad Rzeszutek Wilk @ 2015-01-28 16:17 ` Daniel Kiper 2015-01-28 16:56 ` Jan Beulich 1 sibling, 1 reply; 27+ messages in thread From: Daniel Kiper @ 2015-01-28 16:17 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: Andrew Cooper, Jan Beulich, xen-devel On Wed, Jan 28, 2015 at 11:03:19AM -0500, Konrad Rzeszutek Wilk wrote: > On Wed, Jan 28, 2015 at 08:40:44AM +0000, Jan Beulich wrote: > > >>> On 27.01.15 at 19:20, <konrad.wilk@oracle.com> wrote: > > > On Tue, Jan 27, 2015 at 04:17:05PM +0000, Jan Beulich wrote: > > >> Again - apart from mapping the range, did you also make sure it > > >> didn't get passed to the allocator (and hence couldn't have got > > >> overwritten)? > > > > > > Yes, see patch: > > > > Oh, sorry, I must have not looked closely enough. > > > > > Also see attached of the code with what Linux sees and what Xen sees > > > (Linux first). > > > > Indeed this > > > > 8b: 44 38 2d c2 10 00 00 cmp %r13b,0x10c2(%rip) # 0x115 [01 01 00 00 00 00 00 00][00 01 00 00 00 00 00 00 > > 92: 75 12 jne 0xa6 > > > > causes the code in question to be skipped under Linux. > > > > > I am thinking that the firmware is under the assumption > > > that if SetVirtualAddressMap is not called then you MUST be still > > > before ExitBootServices has been called. Going to verify that by > > > implementing an GetNextVariableName before calling ExitBootServices) > > > > Not sure how exactly you envision to do this, but I'm having a hard > > time seeing how this would prove anything, in particular because > > calling runtime services functions prior to exiting boot services must > > be possible anyway. > > And it works - one of the patches implements an routine to call the > dreaded function before ExitBootServices and it works nicely (ie - I > see: > > Xen 4.6-unstable (c/s Tue Jan 27 14:05:36 2015 -0500 git:332c049-dirty) EFI loader > Using configuration file 'xen.cfg' > vmlinuz-3.19.0-rc4+: 0x00000000cf81a000-0x00000000cfda5f90 > initramfs-3.19.0-rc4+.img: 0x00000000cb522000-0x00000000cd7b04d3 > GetNextVariableName: > 0x8be4df610x93ca0x11d20xaa0xd0x00xe00x980x30x2b0x8c:SimpleBootFlag 0x0 > 0x5e724c0c0x5c030x45430xbc0xb60xc10xe20x3d0xe20x410x36:TpmSaveState 0x0 > 0x6403753b0xabde0x4da20xaa0x110x690x830xef0x2a0x7a0x69:TpmAcpiData 0x0 > 0x8be4df610x93ca0x11d20xaa0xd0x00xe00x980x30x2b0x8c:SetupMode 0x0 > 0x8be4df610x93ca0x11d20xaa0xd0x00xe00x980x30x2b0x8c:SecureBoot 0x0 > 0xe5bbf7be0x24170x499b0x970xdb0x390xf40x890x630x910xbc:BuildDate 0x0 > Could not get next variable > > > It is just that making that call after ExitBootServices does not > work. But on Linux the extra mix is that we also call 'SetVirtualAddressMap' > which we do not do. > > > > And iirc you had already tried calling the function prior to doing much > > else (namely, prior to loading Dom0), and it still crashed? Did you > > Yes, it did crash. That is - we call it _after_ calling ExitBootServices. > > > investigate when the memory type of that region changes (in an > > earlier mail you said dmem from the EFI shell reported it as Boot > > Services, albeit it's not fully clear what that tagging is supposed to > > be telling us)? > > It did not help. Having the mapping of BootServicesData&Code did not > help with the problem. However having disabled the call to > ExitBootServices the mapping of BootServicesData&Code did help - as we > were able to make the proper calls. > > In short, I think the firmware has a bug where it makes the assumption > that if SetVirtualAddressMap then BootServices should _not_ be used > - otherwise it will use it. > > I am not really sure of what the work-around should be in Xen except > making SetVirtualAddressMap work.. Hmmm... Crazy idea. IIRC, we use RS in 1:1 mapping. If we need to call SetVirtualAddressMap() then force it to create 1:1 mapping. Is it possible? Could you try it? I think you should play with code just before SetVirtualAddressMap(). Daniel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-28 16:17 ` Daniel Kiper @ 2015-01-28 16:56 ` Jan Beulich 2015-01-28 17:20 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 27+ messages in thread From: Jan Beulich @ 2015-01-28 16:56 UTC (permalink / raw) To: Daniel Kiper, Konrad Rzeszutek Wilk; +Cc: Andrew Cooper, xen-devel >>> On 28.01.15 at 17:17, <daniel.kiper@oracle.com> wrote: > On Wed, Jan 28, 2015 at 11:03:19AM -0500, Konrad Rzeszutek Wilk wrote: >> I am not really sure of what the work-around should be in Xen except >> making SetVirtualAddressMap work.. > > Hmmm... Crazy idea. IIRC, we use RS in 1:1 mapping. If we need to call > SetVirtualAddressMap() then force it to create 1:1 mapping. Is it > possible? Could you try it? I think you should play with code just > before SetVirtualAddressMap(). Of course this is possible. The reason we don't call the function is kexec: How would the secondary kernel be able to make runtime calls if we already established some mapping? Remember that SetVirtualAddressMap() may not be called more than once... Jan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-28 16:56 ` Jan Beulich @ 2015-01-28 17:20 ` Konrad Rzeszutek Wilk 2015-01-29 10:35 ` Jan Beulich 0 siblings, 1 reply; 27+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-01-28 17:20 UTC (permalink / raw) To: Jan Beulich; +Cc: Andrew Cooper, Daniel Kiper, xen-devel On Wed, Jan 28, 2015 at 04:56:02PM +0000, Jan Beulich wrote: > >>> On 28.01.15 at 17:17, <daniel.kiper@oracle.com> wrote: > > On Wed, Jan 28, 2015 at 11:03:19AM -0500, Konrad Rzeszutek Wilk wrote: > >> I am not really sure of what the work-around should be in Xen except > >> making SetVirtualAddressMap work.. > > > > Hmmm... Crazy idea. IIRC, we use RS in 1:1 mapping. If we need to call > > SetVirtualAddressMap() then force it to create 1:1 mapping. Is it > > possible? Could you try it? I think you should play with code just > > before SetVirtualAddressMap(). > > Of course this is possible. The reason we don't call the function is > kexec: How would the secondary kernel be able to make runtime > calls if we already established some mapping? Remember that > SetVirtualAddressMap() may not be called more than once... Linux does seem to have the code to deal with this, via bootparams. See git 1fec0533693cd74f2d1a46edd29449cfee429df0 Author: Dave Young <dyoung@redhat.com> Date: Fri Dec 20 18:02:19 2013 +0800 x86/efi: Pass necessary EFI data for kexec via setup_data 456a29ddada79198c5965300e04103c40c481f62 Author: Dave Young <dyoung@redhat.com> Date: Fri Dec 20 18:02:20 2013 +0800 x86: Add xloadflags bit for EFI runtime support on kexec Which do: " When entering virtual mode, directly mapping the EFI runtime regions which we passed in previously. And skip the step to call SetVirtualAddressMap(). " ..that could be employed. The problem I had was that I tried to employ SetVirtualAddressMap in the Xen code - but it did not work at all. Jan, do you want me to send you an serial log with a Xen code with SetVirtualAddressMap executed -on a non-Lenovo machine to eliminate the firmware issues? > > Jan > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-28 17:20 ` Konrad Rzeszutek Wilk @ 2015-01-29 10:35 ` Jan Beulich 2015-01-30 14:17 ` Is: kexec & EFI Was: " Konrad Rzeszutek Wilk 0 siblings, 1 reply; 27+ messages in thread From: Jan Beulich @ 2015-01-29 10:35 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: Andrew Cooper, Daniel Kiper, xen-devel >>> On 28.01.15 at 18:20, <konrad.wilk@oracle.com> wrote: > On Wed, Jan 28, 2015 at 04:56:02PM +0000, Jan Beulich wrote: >> >>> On 28.01.15 at 17:17, <daniel.kiper@oracle.com> wrote: >> > On Wed, Jan 28, 2015 at 11:03:19AM -0500, Konrad Rzeszutek Wilk wrote: >> >> I am not really sure of what the work-around should be in Xen except >> >> making SetVirtualAddressMap work.. >> > >> > Hmmm... Crazy idea. IIRC, we use RS in 1:1 mapping. If we need to call >> > SetVirtualAddressMap() then force it to create 1:1 mapping. Is it >> > possible? Could you try it? I think you should play with code just >> > before SetVirtualAddressMap(). >> >> Of course this is possible. The reason we don't call the function is >> kexec: How would the secondary kernel be able to make runtime >> calls if we already established some mapping? Remember that >> SetVirtualAddressMap() may not be called more than once... > > Linux does seem to have the code to deal with this, via bootparams. > See git 1fec0533693cd74f2d1a46edd29449cfee429df0 > Author: Dave Young <dyoung@redhat.com> > Date: Fri Dec 20 18:02:19 2013 +0800 > > x86/efi: Pass necessary EFI data for kexec via setup_data > > 456a29ddada79198c5965300e04103c40c481f62 > Author: Dave Young <dyoung@redhat.com> > Date: Fri Dec 20 18:02:20 2013 +0800 > > x86: Add xloadflags bit for EFI runtime support on kexec Compare the dates of these with that of the Xen commit(s) enabling EFI support. Plus - this protocol is absolutely Linux-centric afaict, whereas Xen's kexec interface/support should be as generic as possible. > ..that could be employed. The problem I had was that I tried to employ > SetVirtualAddressMap in the Xen code - but it did not work at all. > > Jan, do you want me to send you an serial log with a Xen code with > SetVirtualAddressMap executed -on a non-Lenovo machine to eliminate > the firmware issues? Not sure what that would be good for: The commented out code is there just for documentation purposes. It was never expected that you could simply enable it and expect it to work (albeit I _very_ vaguely recall it having worked very early on during development of the EFI support code). Considering how broken the EFI appears to be on that laptop, why don't you simply turn it off (just like is required on many other systems with too early versions of it - reportedly in some cases turning it on renders systems un-bootable, with it being very difficult to turn it back off; I'm supposedly even in possession of such a system, but guess what - I don't want to try it out). Jan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Is: kexec & EFI Was: Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-29 10:35 ` Jan Beulich @ 2015-01-30 14:17 ` Konrad Rzeszutek Wilk 2015-01-30 14:40 ` David Vrabel 0 siblings, 1 reply; 27+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-01-30 14:17 UTC (permalink / raw) To: Jan Beulich, david.vrabel; +Cc: Andrew Cooper, Daniel Kiper, xen-devel On Thu, Jan 29, 2015 at 10:35:08AM +0000, Jan Beulich wrote: > >>> On 28.01.15 at 18:20, <konrad.wilk@oracle.com> wrote: > > On Wed, Jan 28, 2015 at 04:56:02PM +0000, Jan Beulich wrote: > >> >>> On 28.01.15 at 17:17, <daniel.kiper@oracle.com> wrote: > >> > On Wed, Jan 28, 2015 at 11:03:19AM -0500, Konrad Rzeszutek Wilk wrote: > >> >> I am not really sure of what the work-around should be in Xen except > >> >> making SetVirtualAddressMap work.. > >> > > >> > Hmmm... Crazy idea. IIRC, we use RS in 1:1 mapping. If we need to call > >> > SetVirtualAddressMap() then force it to create 1:1 mapping. Is it > >> > possible? Could you try it? I think you should play with code just > >> > before SetVirtualAddressMap(). > >> > >> Of course this is possible. The reason we don't call the function is > >> kexec: How would the secondary kernel be able to make runtime > >> calls if we already established some mapping? Remember that > >> SetVirtualAddressMap() may not be called more than once... > > > > Linux does seem to have the code to deal with this, via bootparams. > > See git 1fec0533693cd74f2d1a46edd29449cfee429df0 > > Author: Dave Young <dyoung@redhat.com> > > Date: Fri Dec 20 18:02:19 2013 +0800 > > > > x86/efi: Pass necessary EFI data for kexec via setup_data > > > > 456a29ddada79198c5965300e04103c40c481f62 > > Author: Dave Young <dyoung@redhat.com> > > Date: Fri Dec 20 18:02:20 2013 +0800 > > > > x86: Add xloadflags bit for EFI runtime support on kexec > > Compare the dates of these with that of the Xen commit(s) enabling > EFI support. Plus - this protocol is absolutely Linux-centric afaict, > whereas Xen's kexec interface/support should be as generic as > possible. <blinks> kexec is OS agnostic? I must have missed that. Either way these two commits are something that the Xen kexec maintainer should probably know about (CCing him). > > > ..that could be employed. The problem I had was that I tried to employ > > SetVirtualAddressMap in the Xen code - but it did not work at all. > > > > Jan, do you want me to send you an serial log with a Xen code with > > SetVirtualAddressMap executed -on a non-Lenovo machine to eliminate > > the firmware issues? > > Not sure what that would be good for: The commented out code is > there just for documentation purposes. It was never expected that > you could simply enable it and expect it to work (albeit I _very_ > vaguely recall it having worked very early on during development of > the EFI support code). Aaah, so dead code. > > Considering how broken the EFI appears to be on that laptop, why > don't you simply turn it off (just like is required on many other > systems with too early versions of it - reportedly in some cases > turning it on renders systems un-bootable, with it being very difficult > to turn it back off; I'm supposedly even in possession of such a > system, but guess what - I don't want to try it out). Haha! > > Jan > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Is: kexec & EFI Was: Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-30 14:17 ` Is: kexec & EFI Was: " Konrad Rzeszutek Wilk @ 2015-01-30 14:40 ` David Vrabel 2015-01-30 14:52 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 27+ messages in thread From: David Vrabel @ 2015-01-30 14:40 UTC (permalink / raw) To: Konrad Rzeszutek Wilk, Jan Beulich; +Cc: Andrew Cooper, Daniel Kiper, xen-devel On 30/01/15 14:17, Konrad Rzeszutek Wilk wrote: > > <blinks> kexec is OS agnostic? Yes. Extra information to be passed to (e.g., a Linux kernel being kexec'd) can be supplied in an additional segment and marshalled into a suitable format/location for the exec'd kernel by purgatory (or similar). There shouldn't be a need to extend the hypervisor ABI for this. David ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Is: kexec & EFI Was: Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-30 14:40 ` David Vrabel @ 2015-01-30 14:52 ` Konrad Rzeszutek Wilk 2015-01-30 14:57 ` David Vrabel 0 siblings, 1 reply; 27+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-01-30 14:52 UTC (permalink / raw) To: David Vrabel; +Cc: Andrew Cooper, Daniel Kiper, Jan Beulich, xen-devel On Fri, Jan 30, 2015 at 02:40:46PM +0000, David Vrabel wrote: > On 30/01/15 14:17, Konrad Rzeszutek Wilk wrote: > > > > <blinks> kexec is OS agnostic? > > Yes. > > Extra information to be passed to (e.g., a Linux kernel being kexec'd) > can be supplied in an additional segment and marshalled into a suitable > format/location for the exec'd kernel by purgatory (or similar). > > There shouldn't be a need to extend the hypervisor ABI for this. How are you planning to make kexec work under EFI? > > David > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Is: kexec & EFI Was: Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-30 14:52 ` Konrad Rzeszutek Wilk @ 2015-01-30 14:57 ` David Vrabel 2015-01-30 15:09 ` Daniel Kiper 0 siblings, 1 reply; 27+ messages in thread From: David Vrabel @ 2015-01-30 14:57 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: Andrew Cooper, Daniel Kiper, Jan Beulich, xen-devel On 30/01/15 14:52, Konrad Rzeszutek Wilk wrote: > On Fri, Jan 30, 2015 at 02:40:46PM +0000, David Vrabel wrote: >> On 30/01/15 14:17, Konrad Rzeszutek Wilk wrote: >>> >>> <blinks> kexec is OS agnostic? >> >> Yes. >> >> Extra information to be passed to (e.g., a Linux kernel being kexec'd) >> can be supplied in an additional segment and marshalled into a suitable >> format/location for the exec'd kernel by purgatory (or similar). >> >> There shouldn't be a need to extend the hypervisor ABI for this. > > How are you planning to make kexec work under EFI? I don't know at this time. David ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Is: kexec & EFI Was: Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-30 14:57 ` David Vrabel @ 2015-01-30 15:09 ` Daniel Kiper 2015-01-30 15:34 ` Jan Beulich 0 siblings, 1 reply; 27+ messages in thread From: Daniel Kiper @ 2015-01-30 15:09 UTC (permalink / raw) To: David Vrabel; +Cc: Andrew Cooper, xen-devel, Jan Beulich On Fri, Jan 30, 2015 at 02:57:32PM +0000, David Vrabel wrote: > On 30/01/15 14:52, Konrad Rzeszutek Wilk wrote: > > On Fri, Jan 30, 2015 at 02:40:46PM +0000, David Vrabel wrote: > >> On 30/01/15 14:17, Konrad Rzeszutek Wilk wrote: > >>> > >>> <blinks> kexec is OS agnostic? > >> > >> Yes. > >> > >> Extra information to be passed to (e.g., a Linux kernel being kexec'd) > >> can be supplied in an additional segment and marshalled into a suitable > >> format/location for the exec'd kernel by purgatory (or similar). > >> > >> There shouldn't be a need to extend the hypervisor ABI for this. > > > > How are you planning to make kexec work under EFI? > > I don't know at this time. I suppose that we should provide additional kexec hypercall function which will return info about RS. kexec-tools should load new kernel as usual and add relevant argument to its command line. Most things are in place so we should just learn kexec-tools to do new things. Daniel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Is: kexec & EFI Was: Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-30 15:09 ` Daniel Kiper @ 2015-01-30 15:34 ` Jan Beulich 2015-01-30 16:24 ` Daniel Kiper 0 siblings, 1 reply; 27+ messages in thread From: Jan Beulich @ 2015-01-30 15:34 UTC (permalink / raw) To: Daniel Kiper; +Cc: Andrew Cooper, David Vrabel, xen-devel >>> On 30.01.15 at 16:09, <daniel.kiper@oracle.com> wrote: > I suppose that we should provide additional kexec hypercall > function which will return info about RS. kexec-tools should > load new kernel as usual and add relevant argument to its > command line. Most things are in place so we should just > learn kexec-tools to do new things. There is a reason why the RS table info can't currently be obtained via a hypercall - Dom0 has nothing to do with it. Plus any kexec-ed kernel (Linux or other) will, under EFI, want this information, so a mechanism by which to pass the information to the secondary kernel without exposing it to entities not having a need to know would be preferable (albeit I have no idea so far how that might look like). Plus, this still doesn't in any way deal with the aspect that was so far discussed in this thread - SetVirtualAddressMap() being callable only once. Jan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Is: kexec & EFI Was: Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-30 15:34 ` Jan Beulich @ 2015-01-30 16:24 ` Daniel Kiper 2015-01-30 16:41 ` Jan Beulich 0 siblings, 1 reply; 27+ messages in thread From: Daniel Kiper @ 2015-01-30 16:24 UTC (permalink / raw) To: Jan Beulich; +Cc: Andrew Cooper, David Vrabel, xen-devel On Fri, Jan 30, 2015 at 03:34:19PM +0000, Jan Beulich wrote: > >>> On 30.01.15 at 16:09, <daniel.kiper@oracle.com> wrote: > > I suppose that we should provide additional kexec hypercall > > function which will return info about RS. kexec-tools should > > load new kernel as usual and add relevant argument to its > > command line. Most things are in place so we should just > > learn kexec-tools to do new things. > > There is a reason why the RS table info can't currently be > obtained via a hypercall - Dom0 has nothing to do with it. Plus any > kexec-ed kernel (Linux or other) will, under EFI, want this > information, so a mechanism by which to pass the information to > the secondary kernel without exposing it to entities not having a > need to know would be preferable (albeit I have no idea so far > how that might look like). Currently, anybody able to use HYPERVISOR_memory_op hypercall on dom0 is able to get full machine memory map. So, what is the problem with exposing more details about RS? Do you think about security? I suppose that we expose to dom0 other hardware details which potentially could be used in malicious way and RS details exposure will not undermine our security so strong. > Plus, this still doesn't in any way deal with the aspect that was > so far discussed in this thread - SetVirtualAddressMap() being > callable only once. Well, we must live with it because this is part of UEFI spec. Or change UEFI spec. Still thinking why spec does not allow OS do this operation more then once. OTH, Konrad pointed out a solution (workaround) for this issue used in Linux which seems sensible and could be used by us too. Daniel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Is: kexec & EFI Was: Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-30 16:24 ` Daniel Kiper @ 2015-01-30 16:41 ` Jan Beulich 0 siblings, 0 replies; 27+ messages in thread From: Jan Beulich @ 2015-01-30 16:41 UTC (permalink / raw) To: Daniel Kiper; +Cc: Andrew Cooper, David Vrabel, xen-devel >>> On 30.01.15 at 17:24, <daniel.kiper@oracle.com> wrote: > On Fri, Jan 30, 2015 at 03:34:19PM +0000, Jan Beulich wrote: >> >>> On 30.01.15 at 16:09, <daniel.kiper@oracle.com> wrote: >> > I suppose that we should provide additional kexec hypercall >> > function which will return info about RS. kexec-tools should >> > load new kernel as usual and add relevant argument to its >> > command line. Most things are in place so we should just >> > learn kexec-tools to do new things. >> >> There is a reason why the RS table info can't currently be >> obtained via a hypercall - Dom0 has nothing to do with it. Plus any >> kexec-ed kernel (Linux or other) will, under EFI, want this >> information, so a mechanism by which to pass the information to >> the secondary kernel without exposing it to entities not having a >> need to know would be preferable (albeit I have no idea so far >> how that might look like). > > Currently, anybody able to use HYPERVISOR_memory_op hypercall on dom0 > is able to get full machine memory map. So, what is the problem with > exposing more details about RS? Do you think about security? I suppose > that we expose to dom0 other hardware details which potentially could > be used in malicious way and RS details exposure will not undermine > our security so strong. I'm not seeing what the exposure of the machine memory map has to do with the RS table. Anyway - my concern isn't a malicious consumer, but an ignorant one (e.g. then trying to make runtime calls directly from Dom0). >> Plus, this still doesn't in any way deal with the aspect that was >> so far discussed in this thread - SetVirtualAddressMap() being >> callable only once. > > Well, we must live with it because this is part of UEFI spec. Or change > UEFI spec. Still thinking why spec does not allow OS do this operation > more then once. OTH, Konrad pointed out a solution (workaround) for this > issue used in Linux which seems sensible and could be used by us too. Like Konrad, you're thinking too Linux-centric here: Yes, a Linux- specific workaround is possible, but a finding a proper generic solution would be much better. And a very obvious one is: Don't call SetVirtualAddressMap() when you may want to kexec. Jan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-27 7:54 ` Jan Beulich 2015-01-27 14:26 ` Konrad Rzeszutek Wilk @ 2015-01-27 20:18 ` Daniel Kiper 2015-01-27 21:48 ` Konrad Rzeszutek Wilk 2015-01-28 8:43 ` Jan Beulich 1 sibling, 2 replies; 27+ messages in thread From: Daniel Kiper @ 2015-01-27 20:18 UTC (permalink / raw) To: Jan Beulich; +Cc: Andrew Cooper, xen-devel On Tue, Jan 27, 2015 at 07:54:30AM +0000, Jan Beulich wrote: > (re-adding xen-devel) > > >>> On 27.01.15 at 01:32, <andrew.cooper3@citrix.com> wrote: > > On 27/01/2015 00:02, Daniel Kiper wrote: > >> On Mon, Jan 26, 2015 at 05:00:41PM +0000, Jan Beulich wrote: > >>>>>> On 26.01.15 at 17:27, <konrad.wilk@oracle.com> wrote: > >>>> Anyhow I am bit stuck: > >>>> 1) It works with Linux, so what is it that Linux does that > >>>> Xen does not? > >>> They map more than just what is marked for runtime use. > >> IIRC, Linux maps boot services unconditionally (and states in comment > >> that this is not in line with spec). We do not have such mechanism. > >> Could we ease life of our users and add a boot option (e.g. map-efi-bs) > >> which will enforce mapping of BS regions on platforms with buggy EFI/UEFI > >> implementations? We should not penalize owners of such hardware because > >> they are not guilty of these crazy bugs. We should educate firmware devs... > >> Ehh... Please, do not curse at me. I remember discussion about EFI reset > >> stuff which happened here a few days ago. > > > > While, in principle, I would like to take a tough stand against buggy > > firmware, the truth is that firmware is always going to be buggy, and > > many users are going to be in a position where their buggy firmware is > > not going to be fixed by their vendors. Much as I would prefer not to, > > I feel that the only rational course of action to take is to behave like > > Linux in cases like this. > > > > Therefore, I am a begrudgingly +1 "work around EFI firmware bugs", > > despite it being the wrong pragmatic thing to do. > > And I agree that we will need to accept in such workarounds. But > two remarks to whoever is going to implement it: We already have I will add this to my TODO list and I will do it with current EFI work (I am going to post it shortly after fixing two issues). > the efi-rs workaround option - we should deprecate that one, and > have a consolidated efi= one instead, covering the case here too. OK. > Plus the issue here is not just a matter of mapping BS memory, but > also not making it available to the allocator. That in turn may yield Yep, however, I thought that if a memory region is reserved in E820 then it is also automatically removed from allocator pool. > problems with the conversion of the EFI memory map to E820 form, > both because of the number of entries needed, and because that In worst case we can try to allocate E820 map dynamically or ignore this option completely if new map do not fit in statically allocated E820 memory map region. > conversion happens _before_ the normal command line parsing. I am going to align EFI early command line parser to legacy BIOS early boot path parser (I think about vga command line option). So, I think that this EFI "bug" work could be based on it. Daniel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-27 20:18 ` Daniel Kiper @ 2015-01-27 21:48 ` Konrad Rzeszutek Wilk 2015-01-28 8:43 ` Jan Beulich 1 sibling, 0 replies; 27+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-01-27 21:48 UTC (permalink / raw) To: Daniel Kiper, Marcos Matsunaga; +Cc: Andrew Cooper, Jan Beulich, xen-devel [-- Attachment #1: Type: text/plain, Size: 8215 bytes --] On Tue, Jan 27, 2015 at 09:18:58PM +0100, Daniel Kiper wrote: > On Tue, Jan 27, 2015 at 07:54:30AM +0000, Jan Beulich wrote: > > (re-adding xen-devel) > > > > >>> On 27.01.15 at 01:32, <andrew.cooper3@citrix.com> wrote: > > > On 27/01/2015 00:02, Daniel Kiper wrote: > > >> On Mon, Jan 26, 2015 at 05:00:41PM +0000, Jan Beulich wrote: > > >>>>>> On 26.01.15 at 17:27, <konrad.wilk@oracle.com> wrote: > > >>>> Anyhow I am bit stuck: > > >>>> 1) It works with Linux, so what is it that Linux does that > > >>>> Xen does not? > > >>> They map more than just what is marked for runtime use. And they call SetVirtualAddressMap which we do not (and if I define USE_SET_VIRTUAL_ADDRESS_MAP Xen blows up during bootup). > > >> IIRC, Linux maps boot services unconditionally (and states in comment > > >> that this is not in line with spec). We do not have such mechanism. .. snip.. I've found that the issue is that the EFI firmware code assumes that if you have not called SetVirtualAddressMap then you must have not called ExitBootServices. But we do, and part of ExitBootServices job is to wipe out its system function table to zero. And since we did that - the system function table would point to zeros .. and the code would happily execute code at location 0 <facepalm>. The "fix" was to not call ExitBootServices. See patches - which are really just for diagnostic purposes. Daniel - thank you for suggesting that! P.S. Marcos, you might want to run with these patches (except the #4 patch) - and see how it works on your Dell machine (without the efi-rs=0 workaround). For those that are interested, here is the heavily annotated efi_rs->GetNextVariableName code on this Lenovo Thinkpad along with snippets from memory: The first [] is when running under Linux, the second is when running under Xen. The [S] means it had the same value when running w/ calling ExitBootServices under Xen. 0: 48 89 5c 24 08 mov %rbx,0x8(%rsp) 5: 48 89 6c 24 10 mov %rbp,0x10(%rsp) a: 48 89 74 24 18 mov %rsi,0x18(%rsp) f: 57 push %rdi 10: 41 54 push %r12 12: 41 55 push %r13 14: 48 83 ec 20 sub $0x20,%rsp 18: 45 33 ed xor %r13d,%r13d 1b: 48 85 c9 test %rcx,%rcx 1e: 4d 8b e0 mov %r8,%r12 21: 48 8b fa mov %rdx,%rdi 24: 48 8b e9 mov %rcx,%rbp 27: 0f 84 09 01 00 00 je 0x136 2d: 48 85 d2 test %rdx,%rdx 30: 0f 84 00 01 00 00 je 0x136 36: 4d 85 c0 test %r8,%r8 39: 0f 84 f7 00 00 00 je 0x136 3f: 48 8b 05 76 11 00 00 mov 0x1176(%rip),%rax # 0x11bc [20 53 c3 fa fe ff ff ff] [20 53 a3 d6 00 00 00 00][S] 46: 48 8d 15 af 11 00 00 lea 0x11af(%rip),%rdx # 0x11fc [00 54 f3 41 60 06 1c 8] [00 6d 15 d8 d6 db 40 8d][S] 4d: 48 8b c8 mov %rax,%rcx 50: ff 50 20 callq *0x20(%rax) 53: 80 3d a2 11 00 00 01 cmpb $0x1,0x11a2(%rip) # 0x11fc [00 54 f3 41 60 06 1c 8] [00 6d 15 d8 d6 db 40 8d][S] 5a: 75 1b jne 0x77 5c: 48 8b 05 81 11 00 00 mov 0x1181(%rip),%rax # 0x11e4 [80 62 2b db 00 00 00 00] [80 62 2b db 00 00 00 0][S] 63: 4d 8b c4 mov %r12,%r8 66: 48 8b d7 mov %rdi,%rdx 69: 48 8b cd mov %rbp,%rcx 6c: ff 50 08 callq *0x8(%rax) 6f: 48 8b d8 mov %rax,%rbx 72: e9 ba 00 00 00 jmpq 0x131 77: 48 8b cf mov %rdi,%rcx 7a: e8 bd 0f 00 00 callq 0x103c 7f: 48 3d 00 01 00 00 cmp $0x100,%rax 85: 0f 87 ab 00 00 00 ja 0x136 8b: 44 38 2d c2 10 00 00 cmp %r13b,0x10c2(%rip) # 0x1154 [01 01 00 00 00 00 00 00] [00 01 00 00 00 00 00 00][S] [Here we figure out whether to use BootServices. r13 is zero (see @18)] 92: 75 12 jne 0xa6 [Linux: 01 != 00, hence go to @a6, Xen keeps on going] 94: 48 8b 05 d1 10 00 00 mov 0x10d1(%rip),%rax # 0x116c [70 a2 db cf 00 00 00 00][70 a2 db cf 00 00 00 00][S] 9b: b9 1f 00 00 00 mov $0x1f,%ecx w/o ExitBootServices: [@cfdba270: 42 4f 4f 54 53 45 52 56] [@cfdba270+0x18: 48 30 dc cf 00 00 00 00] [@0: 68 02 00 f0 68 02 00 f0 6].. w/ ExitBootServices they [@cfdba270: 00 00 00 ...] [@cfdba270+0x18: 00 00 00 ..] [@0: 68 02 00 f0 68 02 00 f0 6].. a0: ff 50 18 callq *0x18(%rax) .. and the rest is unintersting - as right now Xen would crash when calling code at @0 which ends is full of garbage. If however we did not call ExitBootServices, we jump to cfdc3048 which is: 0: 48 89 5c 24 08 mov %rbx,0x8(%rsp) 5: 57 push %rdi 6: 48 83 ec 20 sub $0x20,%rsp a: 48 8b 1d 57 81 ff ff mov -0x7ea9(%rip),%rbx # 0xffffffffffff8168 11: 48 8b f9 mov %rcx,%rdi 14: 48 3b cb cmp %rbx,%rcx 17: 72 1a jb 0x33 19: 48 83 f9 1f cmp $0x1f,%rcx 1d: 72 0d jb 0x2c 1f: 48 83 fb 1f cmp $0x1f,%rbx 23: 73 07 jae 0x2c 25: 33 c9 xor %ecx,%ecx 27: e8 9c ff ff ff callq 0xffffffffffffffc8 2c: 48 89 3d 35 81 ff ff mov %rdi,-0x7ecb(%rip) # 0xffffffffffff8168 33: 48 8b c3 mov %rbx,%rax 36: 48 8b 5c 24 30 mov 0x30(%rsp),%rbx 3b: 48 83 c4 20 add $0x20,%rsp 3f: 5f pop %rdi 40: c3 retq a3: 4c 8b e8 mov %rax,%r13 a6: 48 8b 35 27 11 00 00 mov 0x1127(%rip),%rsi # 0x11d4 [10 d0 87 fa fe ff ff ff][10 d0 47 da 00 00 00 00][S] ad: 48 8b d7 mov %rdi,%rdx b0: c6 06 5a movb $0x5a,(%rsi) b3: c6 46 01 6b movb $0x6b,0x1(%rsi) b7: 48 8b 4d 00 mov 0x0(%rbp),%rcx bb: 48 89 4e 18 mov %rcx,0x18(%rsi) bf: 48 8d 4e 20 lea 0x20(%rsi),%rcx c3: e8 58 0f 00 00 callq 0x1020 c8: 48 8d 8e 20 02 00 00 lea 0x220(%rsi),%rcx cf: 41 b8 10 00 00 00 mov $0x10,%r8d d5: 49 8b d4 mov %r12,%rdx d8: e8 ff 0e 00 00 callq 0xfdc dd: e8 3a fb ff ff callq 0xfffffffffffffc1c e2: 44 8a 1e mov (%rsi),%r11b e5: 41 80 fb 5a cmp $0x5a,%r11b e9: 74 bb je 0xa6 eb: 48 8b 5e 08 mov 0x8(%rsi),%rbx ef: 48 8b 46 18 mov 0x18(%rsi),%rax f3: 48 85 db test %rbx,%rbx f6: 48 89 45 00 mov %rax,0x0(%rbp) fa: 75 1f jne 0x11b fc: 48 8d 56 20 lea 0x20(%rsi),%rdx 100: 48 8b cf mov %rdi,%rcx 103: e8 18 0f 00 00 callq 0x1020 108: 48 8d 96 20 02 00 00 lea 0x220(%rsi),%rdx 10f: 44 8d 43 10 lea 0x10(%rbx),%r8d 113: 49 8b cc mov %r12,%rcx 116: e8 c1 0e 00 00 callq 0xfdc 11b: 80 3d 32 10 00 00 00 cmpb $0x0,0x1032(%rip) # 0x1154 [70 a2 db cf 00 00 00 00][00 01 00 00 00 00 00 00][S] 122: 75 0d jne 0x131 124: 48 8b 05 41 10 00 00 mov 0x1041(%rip),%rax # 0x116c [70 a2 db cf 00 00 00 00][70 a2 db cf 00 00 00 00][S] 12b: 49 8b cd mov %r13,%rcx 12e: ff 50 20 callq *0x20(%rax) 131: 48 8b c3 mov %rbx,%rax 134: eb 0a jmp 0x140 136: 48 b8 02 00 00 00 00 movabs $0x8000000000000002,%rax 13d: 00 00 80 140: 48 8b 5c 24 40 mov 0x40(%rsp),%rbx 145: 48 8b 6c 24 48 mov 0x48(%rsp),%rbp 14a: 48 8b 74 24 50 mov 0x50(%rsp),%rsi 14f: 48 83 c4 20 add $0x20,%rsp 153: 41 5d pop %r13 155: 41 5c pop %r12 157: 5f pop %rdi 158: c3 retq 159: cc int3 15a: cc int3 15b: cc int3 [-- Attachment #2: 0001-EFI-Map-also-BootServicesData-and-BootServicesCode.patch --] [-- Type: text/plain, Size: 3574 bytes --] >From 49aab3d6e623c907164475403ba495ede442e6e5 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Tue, 27 Jan 2015 15:32:10 -0500 Subject: [PATCH 1/4] EFI: Map also BootServicesData and BootServicesCode Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- xen/arch/x86/efi/efi-boot.h | 2 -- xen/common/efi/boot.c | 27 ++++++++++++++++++++++++--- 2 files changed, 24 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h index 3a3b4fe..c3bdb8d 100644 --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -152,8 +152,6 @@ static void __init efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable, type = E820_RESERVED; break; case EfiConventionalMemory: - case EfiBootServicesCode: - case EfiBootServicesData: if ( !trampoline_phys && desc->PhysicalStart + len <= 0x100000 && len >= cfg.size && desc->PhysicalStart + len > cfg.addr ) cfg.addr = (desc->PhysicalStart + len - cfg.size) & PAGE_MASK; diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index c04e0a2..b0bbc4b 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -1156,13 +1156,23 @@ void __init efi_init_memory(void) u64 len = desc->NumberOfPages << EFI_PAGE_SHIFT; unsigned long smfn, emfn; unsigned int prot = PAGE_HYPERVISOR; + unsigned int skip = 1; printk(XENLOG_INFO " %013" PRIx64 "-%013" PRIx64 " type=%u attr=%016" PRIx64 "\n", desc->PhysicalStart, desc->PhysicalStart + len - 1, desc->Type, desc->Attribute); - if ( !efi_rs_enable || !(desc->Attribute & EFI_MEMORY_RUNTIME) ) + if ( desc->Attribute & EFI_MEMORY_RUNTIME ) + skip = 0; + + if ( desc->Type == 4 && desc->Attribute != 0 ) + skip = 0; + + if ( desc->Type == 3 && desc->Attribute != 0 ) + skip = 0; + + if ( !efi_rs_enable || skip ) { printk(XENLOG_INFO " .. skipped!\n"); continue; @@ -1246,18 +1256,29 @@ void __init efi_init_memory(void) copy_mapping(0, max_page, ram_range_valid); + printk(XENLOG_INFO "Copying..\n"); /* Insert non-RAM runtime mappings inside the direct map. */ for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size ) { const EFI_MEMORY_DESCRIPTOR *desc = efi_memmap + i; - if ( (desc->Attribute & EFI_MEMORY_RUNTIME) && + if ( ((desc->Attribute & EFI_MEMORY_RUNTIME) || + (desc->Type == 3 && desc->Attribute != 0 ) || + (desc->Type == 4 && desc->Attribute != 0 )) && desc->VirtualStart != INVALID_VIRTUAL_ADDRESS && - desc->VirtualStart != desc->PhysicalStart ) + desc->VirtualStart != desc->PhysicalStart ) { + + printk(XENLOG_INFO " %013" PRIx64 "-%013" PRIx64 + " type=%u attr=%016" PRIx64 "\n", + PFN_DOWN(desc->PhysicalStart), + PFN_UP(desc->PhysicalStart + (desc->NumberOfPages << EFI_PAGE_SHIFT)), + desc->Type, desc->Attribute); + copy_mapping(PFN_DOWN(desc->PhysicalStart), PFN_UP(desc->PhysicalStart + (desc->NumberOfPages << EFI_PAGE_SHIFT)), rt_range_valid); + } } /* Insert non-RAM runtime mappings outside of the direct map. */ -- 2.1.0 [-- Attachment #3: 0002-EFI-early-Implement-GetNextVariableName-and-query-an.patch --] [-- Type: text/plain, Size: 4581 bytes --] >From ffb09e4938021ed47bc7097585dd19a10f2e09de Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Tue, 27 Jan 2015 14:04:30 -0500 Subject: [PATCH 2/4] EFI/early: Implement GetNextVariableName and /query and /noexitboot parameters In the early EFI boot we will enumerate up to five EFI variables to make sure it works. The /query will just enumerate them and then quit. Helps in troubleshooting and redirecting the output to a file (xen.efi /query > q). The /noexitboot will inhibit Xen from calling ExitBootServices. This allows on Lenovo ThinkPad x230 to use GetNextVariableName in 1-1 mapping mode. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- xen/common/efi/boot.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 82 insertions(+), 1 deletion(-) diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index b0bbc4b..4ee8f68 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -673,6 +673,74 @@ static void __init setup_efi_pci(void) efi_bs->FreePool(handles); } +static int __init efi_getnextvariable(bool_t query_only) +{ + EFI_GUID guid; + UINTN i, size, idx; + CHAR16 *name; + EFI_STATUS status; + + + status = efi_bs->AllocatePool(EfiLoaderData, 1024, (void *)&name); + if ( EFI_ERROR(status) ) + return status; + + guid.Data1 = 0; + guid.Data2 = 0; + guid.Data3 = 0; + for ( i = 0; i < 8; i++ ) + guid.Data4[i] = 0; + + for ( i = 0 ; i < 1024 / sizeof (CHAR16); i++ ) + name[i] = 0; + + PrintStr(L"GetNextVariableName: "); + PrintStr(name); + PrintStr(newline); + idx = 0; + do { + size = 1024; + efi_rs->GetNextVariableName(&size, name, &guid); + if ( EFI_ERROR(status) ) + { + if ( query_only ) + { + efi_bs->FreePool(name); + PrintErrMesg(L"Failed to GetNextVariableName", status); + } + else + { + PrintStr(L"Warning: GetNextVariableName: "); + DisplayUint(status, 0); + PrintStr(newline); + } + } + else + { + DisplayUint(guid.Data1, 4); + DisplayUint(guid.Data2, 2); + DisplayUint(guid.Data3, 2); + for ( i = 0; i < 8; i++ ) + DisplayUint(guid.Data4[i], 1); + + PrintStr(L":"); + PrintStr(name); + PrintStr(L" "); + DisplayUint(status, 0); + PrintStr(newline); + } + } while ( !EFI_ERROR(status) && idx++ < 5 ); + + efi_bs->FreePool(name); + + if ( query_only ) + return -EINVAL; + + if ( EFI_ERROR(EFI_NOT_FOUND) ) + return 0; + + return status; +} static int __init __maybe_unused set_color(u32 mask, int bpp, u8 *pos, u8 *sz) { if ( bpp < 0 ) @@ -705,8 +773,10 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info; union string section = { NULL }, name; bool_t base_video = 0, retry; + bool_t query_only = 0; char *option_str; bool_t use_cfg_file; + bool_t exit_boot_services = 0; efi_ih = ImageHandle; efi_bs = SystemTable->BootServices; @@ -751,6 +821,10 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) { if ( wstrcmp(ptr + 1, L"basevideo") == 0 ) base_video = 1; + else if ( wstrcmp(ptr + 1, L"query") == 0 ) + query_only = 1; + else if ( wstrcmp(ptr + 1, L"noexitboot") == 0 ) + exit_boot_services = 0; else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 ) cfg_file_name = ptr + 5; else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 ) @@ -1031,6 +1105,9 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) PrintStr(newline); } + if ( efi_getnextvariable(query_only) ) + blexit(L"Could not get next variable"); + efi_arch_memory_setup(); if ( gop ) @@ -1064,7 +1141,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) efi_arch_pre_exit_boot(); - status = efi_bs->ExitBootServices(ImageHandle, map_key); + if ( exit_boot_services ) + status = efi_bs->ExitBootServices(ImageHandle, map_key); + else + status = 0; + if ( status != EFI_INVALID_PARAMETER || retry ) break; } -- 2.1.0 [-- Attachment #4: 0003-EFI-early-Swap-noexitboot-to-exitboot-and-by-default.patch --] [-- Type: text/plain, Size: 1801 bytes --] >From 76bee287621d22b2c9082eae6eacfea2446722c9 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Tue, 27 Jan 2015 15:35:35 -0500 Subject: [PATCH 3/4] EFI/early: Swap noexitboot to exitboot and by default don't call ExitBootServices. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- xen/common/efi/boot.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index 4ee8f68..d9aabd3 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -823,8 +823,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) base_video = 1; else if ( wstrcmp(ptr + 1, L"query") == 0 ) query_only = 1; - else if ( wstrcmp(ptr + 1, L"noexitboot") == 0 ) - exit_boot_services = 0; + else if ( wstrcmp(ptr + 1, L"exitboot") == 0 ) + exit_boot_services = 1; else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 ) cfg_file_name = ptr + 5; else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 ) @@ -834,6 +834,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) { PrintStr(L"Xen EFI Loader options:\r\n"); PrintStr(L"-basevideo retain current video mode\r\n"); + PrintStr(L"-exitboot call ExitBootServices\r\n"); + PrintStr(L"-query call GetNextVariableName for up to five times\r\n"); PrintStr(L"-cfg=<file> specify configuration file\r\n"); PrintStr(L"-help, -? display this help\r\n"); blexit(NULL); -- 2.1.0 [-- Attachment #5: 0004-EFI-Dump-0xcfda270-and-the-other-address.patch --] [-- Type: text/plain, Size: 931 bytes --] >From 9f7469cd3b8a89594b16f2e39886948987bfa2ae Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Tue, 27 Jan 2015 16:09:51 -0500 Subject: [PATCH 4/4] EFI: Dump 0xcfda270 and the other address Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- xen/common/efi/runtime.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c index ef6b1df..79e8072 100644 --- a/xen/common/efi/runtime.c +++ b/xen/common/efi/runtime.c @@ -236,7 +236,12 @@ long __init efi_debug(void) printk(", GetNextVariableName: %lx\n", get); _dumpcode(get, get+1024); - + get = 0xcfdba270; + _dumpcode(get, get+8); + _dumpcode(get + 0x18, get + 0x18 + 8); + _dumpcode(get + 0x20, get + 0x20 + 8); + get = 0xcfdc3048; + _dumpcode(get, get+1024); idx = 1; do { printk("%4d:", idx++); -- 2.1.0 [-- Attachment #6: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-27 20:18 ` Daniel Kiper 2015-01-27 21:48 ` Konrad Rzeszutek Wilk @ 2015-01-28 8:43 ` Jan Beulich 2015-01-28 12:57 ` Daniel Kiper 1 sibling, 1 reply; 27+ messages in thread From: Jan Beulich @ 2015-01-28 8:43 UTC (permalink / raw) To: Daniel Kiper; +Cc: Andrew Cooper, xen-devel >>> On 27.01.15 at 21:18, <daniel.kiper@oracle.com> wrote: > On Tue, Jan 27, 2015 at 07:54:30AM +0000, Jan Beulich wrote: >> Plus the issue here is not just a matter of mapping BS memory, but >> also not making it available to the allocator. That in turn may yield > > Yep, however, I thought that if a memory region is reserved in E820 > then it is also automatically removed from allocator pool. That's correct. >> conversion happens _before_ the normal command line parsing. > > I am going to align EFI early command line parser to legacy > BIOS early boot path parser (I think about vga command line > option). So, I think that this EFI "bug" work could be based > on it. The vga option is completely meaningless under EFI. And any such workaround implementation would ideally be done in a backportable way, i.e. without depending on a huge pile of other changes. Jan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-28 8:43 ` Jan Beulich @ 2015-01-28 12:57 ` Daniel Kiper 2015-01-28 14:02 ` Jan Beulich 0 siblings, 1 reply; 27+ messages in thread From: Daniel Kiper @ 2015-01-28 12:57 UTC (permalink / raw) To: Jan Beulich; +Cc: Andrew Cooper, xen-devel On Wed, Jan 28, 2015 at 08:43:19AM +0000, Jan Beulich wrote: > >>> On 27.01.15 at 21:18, <daniel.kiper@oracle.com> wrote: > > On Tue, Jan 27, 2015 at 07:54:30AM +0000, Jan Beulich wrote: > >> Plus the issue here is not just a matter of mapping BS memory, but > >> also not making it available to the allocator. That in turn may yield > > > > Yep, however, I thought that if a memory region is reserved in E820 > > then it is also automatically removed from allocator pool. > > That's correct. > > >> conversion happens _before_ the normal command line parsing. > > > > I am going to align EFI early command line parser to legacy > > BIOS early boot path parser (I think about vga command line > > option). So, I think that this EFI "bug" work could be based > > on it. > > The vga option is completely meaningless under EFI. And any such Yep, I know that we have GOP there. I meant that user should have a chance to choose arbitrary mode like in case of VGA. Currently, he or she could only rely on automatic mode detection or just disable this mechanism. So, I think we should implement vga option (or rename it to gop) as is (maybe with some minor changes) in early EFI code. > workaround implementation would ideally be done in a backportable > way, i.e. without depending on a huge pile of other changes. We add more and more early options, so, maybe we could workout something generic, easily reusable in other cases. Daniel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues 2015-01-28 12:57 ` Daniel Kiper @ 2015-01-28 14:02 ` Jan Beulich 0 siblings, 0 replies; 27+ messages in thread From: Jan Beulich @ 2015-01-28 14:02 UTC (permalink / raw) To: Daniel Kiper; +Cc: Andrew Cooper, xen-devel >>> On 28.01.15 at 13:57, <daniel.kiper@oracle.com> wrote: > On Wed, Jan 28, 2015 at 08:43:19AM +0000, Jan Beulich wrote: >> >>> On 27.01.15 at 21:18, <daniel.kiper@oracle.com> wrote: >> > I am going to align EFI early command line parser to legacy >> > BIOS early boot path parser (I think about vga command line >> > option). So, I think that this EFI "bug" work could be based >> > on it. >> >> The vga option is completely meaningless under EFI. And any such > > Yep, I know that we have GOP there. I meant that user should have > a chance to choose arbitrary mode like in case of VGA. Currently, > he or she could only rely on automatic mode detection or just disable > this mechanism. So, I think we should implement vga option (or rename > it to gop) as is (maybe with some minor changes) in early EFI code. Sounds like you haven't seen the video= config file option... >> workaround implementation would ideally be done in a backportable >> way, i.e. without depending on a huge pile of other changes. > > We add more and more early options, so, maybe we could workout > something generic, easily reusable in other cases. Early options are different from the need to control the bootloader part of xen.efi. Jan ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2015-01-30 16:41 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-26 16:27 EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues Konrad Rzeszutek Wilk 2015-01-26 16:36 ` Andrew Cooper 2015-01-26 17:28 ` Konrad Rzeszutek Wilk [not found] ` <54C680C90200007800059907@mail.emea.novell.com> [not found] ` <20150127000247.GU3473@olila.local.net-space.pl> [not found] ` <54C6DCB7.3060206@citrix.com> 2015-01-27 7:54 ` Jan Beulich 2015-01-27 14:26 ` Konrad Rzeszutek Wilk 2015-01-27 16:17 ` Jan Beulich 2015-01-27 18:20 ` Konrad Rzeszutek Wilk 2015-01-28 8:40 ` Jan Beulich 2015-01-28 16:03 ` Konrad Rzeszutek Wilk 2015-01-28 16:12 ` Konrad Rzeszutek Wilk 2015-01-28 16:17 ` Daniel Kiper 2015-01-28 16:56 ` Jan Beulich 2015-01-28 17:20 ` Konrad Rzeszutek Wilk 2015-01-29 10:35 ` Jan Beulich 2015-01-30 14:17 ` Is: kexec & EFI Was: " Konrad Rzeszutek Wilk 2015-01-30 14:40 ` David Vrabel 2015-01-30 14:52 ` Konrad Rzeszutek Wilk 2015-01-30 14:57 ` David Vrabel 2015-01-30 15:09 ` Daniel Kiper 2015-01-30 15:34 ` Jan Beulich 2015-01-30 16:24 ` Daniel Kiper 2015-01-30 16:41 ` Jan Beulich 2015-01-27 20:18 ` Daniel Kiper 2015-01-27 21:48 ` Konrad Rzeszutek Wilk 2015-01-28 8:43 ` Jan Beulich 2015-01-28 12:57 ` Daniel Kiper 2015-01-28 14:02 ` 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.