* 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
* 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 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 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-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
* 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
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.