[Xen-devel] Likely regression in efi=no-rs option

[Xen-devel] Likely regression in efi=no-rs option

[Roman Shaposhnik]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

Hi!

as I've reported earlier -- part of my testing of Xen 4.13 RC2 failed
in a massive way with Dom0 never coming up. I've traced that problem
to the option that we're using to boot Xen:
    efi=no-rs
We've been using this option for quite sometime and Xen 4.13 RC2
is the first one that seems to make Dom0 boot fail with this option
present (note that RC1 was fine).

I was wondering whether there were any changes in the areas related
to UEFI in Xen that may have triggered this.

Here's the boot line that works with RC2:
    dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
adding efi=no-rs make Dom0 boot process fail:
    efi=no-rs dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin smt=false

Attaching xl info and dmesg just in case

Thanks,
Roman.

[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 15295 bytes --]

 Xen 4.13.0-rc
(XEN) Xen version 4.13.0-rc (@) (gcc (Alpine 6.4.0) 6.4.0) debug=y  Thu Nov 14 06:43:01 UTC 2019
(XEN) Latest ChangeSet: 
(XEN) build-id: 3cf9f737e7ebc3c92024f33583302bdacd36b883
(XEN) Bootloader: GRUB 2.03
(XEN) Command line: dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
(XEN) Xen image load base address: 0x88000000
(XEN) Video information:
(XEN)  VGA is graphics mode 1680x1050, 32 bpp
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) EFI RAM map:
(XEN)  0000000000000000 - 0000000000058000 (usable)
(XEN)  0000000000058000 - 0000000000059000 (reserved)
(XEN)  0000000000059000 - 000000000009f000 (usable)
(XEN)  000000000009f000 - 00000000000a0000 (reserved)
(XEN)  0000000000100000 - 000000008648a000 (usable)
(XEN)  000000008648a000 - 000000008648b000 (ACPI NVS)
(XEN)  000000008648b000 - 00000000864b5000 (reserved)
(XEN)  00000000864b5000 - 000000008c224000 (usable)
(XEN)  000000008c224000 - 000000008c528000 (reserved)
(XEN)  000000008c528000 - 000000008c736000 (usable)
(XEN)  000000008c736000 - 000000008cea7000 (ACPI NVS)
(XEN)  000000008cea7000 - 000000008d2ff000 (reserved)
(XEN)  000000008d2ff000 - 000000008d300000 (usable)
(XEN)  000000008d300000 - 000000008d400000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fe000000 - 00000000fe011000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000016e000000 (usable)
(XEN) ACPI: RSDP 8CE49000, 0024 (r2 ALASKA)
(XEN) ACPI: XSDT 8CE490A8, 00CC (r1 ALASKA   A M I   1072009 AMI     10013)
(XEN) ACPI: FACP 8CE6C370, 010C (r5 ALASKA   A M I   1072009 AMI     10013)
(XEN) ACPI: DSDT 8CE49208, 23167 (r2 ALASKA   A M I   1072009 INTL 20120913)
(XEN) ACPI: FACS 8CE8EF80, 0040
(XEN) ACPI: APIC 8CE6C480, 0084 (r3 ALASKA   A M I   1072009 AMI     10013)
(XEN) ACPI: FPDT 8CE6C508, 0044 (r1 ALASKA   A M I   1072009 AMI     10013)
(XEN) ACPI: FIDT 8CE6C550, 009C (r1 ALASKA   A M I   1072009 AMI     10013)
(XEN) ACPI: MCFG 8CE6C5F0, 003C (r1 ALASKA   A M I   1072009 MSFT       97)
(XEN) ACPI: HPET 8CE6C630, 0038 (r1 ALASKA   A M I   1072009 AMI.    5000B)
(XEN) ACPI: LPIT 8CE6C668, 0094 (r1 INTEL   SKL-ULT        0 MSFT       5F)
(XEN) ACPI: SSDT 8CE6C700, 0248 (r2 INTEL  sensrhub        0 INTL 20120913)
(XEN) ACPI: SSDT 8CE6C948, 2BAE (r2 INTEL  PtidDevc     1000 INTL 20120913)
(XEN) ACPI: SSDT 8CE6F4F8, 0BE3 (r2 INTEL  Ther_Rvp     1000 INTL 20120913)
(XEN) ACPI: SSDT 8CE700E0, 04A3 (r2 INTEL     zpodd     1000 INTL 20120913)
(XEN) ACPI: DBGP 8CE70588, 0034 (r1 INTEL                  0 MSFT       5F)
(XEN) ACPI: DBG2 8CE705C0, 0054 (r0 INTEL                  0 MSFT       5F)
(XEN) ACPI: SSDT 8CE70618, 06E9 (r2  INTEL xh_rvp07        0 INTL 20120913)
(XEN) ACPI: SSDT 8CE70D08, 547E (r2 SaSsdt  SaSsdt      3000 INTL 20120913)
(XEN) ACPI: UEFI 8CE76188, 0042 (r1                        0             0)
(XEN) ACPI: SSDT 8CE761D0, 0E73 (r2 CpuRef  CpuSsdt     3000 INTL 20120913)
(XEN) ACPI: BGRT 8CE77048, 0038 (r1 ALASKA   A M I   1072009 AMI     10013)
(XEN) ACPI: DMAR 8CE77080, 00A8 (r1 INTEL      SKL         1 INTL        1)
(XEN) ACPI: TPM2 8CE77128, 0034 (r3        Tpm2Tabl        1 AMI         0)
(XEN) ACPI: ASF! 8CE77160, 00A5 (r32 INTEL       HCG        1 TFSM    F4240)
(XEN) System RAM: 4003MB (4099736kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000016e000000
(XEN) Domain heap initialised
(XEN) vesafb: framebuffer at 0x00000000c0000000, mapped to 0xffff82c000201000, using 6912k, total 6912k
(XEN) vesafb: mode is 1680x1050x32, linelength=6720, font 8x16
(XEN) vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
(XEN) CPU Vendor: Intel, Family 6 (0x6), Model 78 (0x4e), Stepping 3 (raw 000406e3)
(XEN) SMBIOS 3.0 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1808 (32 bits)
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1804,1:0], pm1x_evt[1:1800,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - 8ce8ef80/0000000000000000, using 32
(XEN) ACPI:             wakeup_vec[8ce8ef8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] 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-119
(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: 0x8086a701 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-ff
(XEN) [VT-D]  RMRR address range 8d800000..8fffffff not in reserved memory; need "iommu_inclusive_mapping=1"?
(XEN) ACPI: BGRT: invalidating v1 image at 0x88e5a018
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 120 GSI, 840 MSI/MSI-X
(XEN) Switched to APIC driver x2apic_cluster
(XEN) xstate: size: 0x440 and states: 0x1f
(XEN) mce_intel.c:778: MCA Capability: firstbank 0, extended MCE MSR 0, BCAST, CMCI
(XEN) CPU0: Intel machine check reporting enabled
(XEN) Speculative mitigation facilities:
(XEN)   Hardware features:
(XEN)   Compiled-in support: SHADOW_PAGING
(XEN)   Xen settings: BTI-Thunk N/A, SPEC_CTRL: No, Other: BRANCH_HARDEN
(XEN)   L1TF: believed vulnerable, maxphysaddr L1D 46, CPUID 39, Safe address 8000000000
(XEN)   Support for HVM VMs: RSB EAGER_FPU
(XEN)   Support for PV VMs: RSB EAGER_FPU
(XEN)   XPTI (64-bit PV only): Dom0 enabled, DomU enabled (with PCID)
(XEN)   PV L1TF shadowing: Dom0 disabled, DomU enabled
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN)  load_precision_shift: 18
(XEN)  load_window_shift: 30
(XEN)  underload_balance_tolerance: 0
(XEN)  overload_balance_tolerance: -3
(XEN)  runqueues arrangement: socket
(XEN)  cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Platform timer is 23.999MHz HPET
(XEN) Detected 2496.180 MHz processor.
(XEN) EFI memory map:
(XEN)  0000000000000-0000000007fff type=3 attr=000000000000000f
(XEN)  0000000008000-000000000bfff type=2 attr=000000000000000f
(XEN)  000000000c000-0000000047fff type=7 attr=000000000000000f
(XEN)  0000000048000-0000000057fff type=2 attr=000000000000000f
(XEN)  0000000058000-0000000058fff type=0 attr=000000000000000f
(XEN)  0000000059000-000000005efff type=7 attr=000000000000000f
(XEN)  000000005f000-000000005ffff type=4 attr=000000000000000f
(XEN)  0000000060000-000000009efff type=3 attr=000000000000000f
(XEN)  000000009f000-000000009ffff type=0 attr=000000000000000f
(XEN)  0000000100000-00000008c0fff type=2 attr=000000000000000f
(XEN)  00000008c1000-0000043fe1fff type=7 attr=000000000000000f
(XEN)  0000043fe2000-000007e51ffff type=1 attr=000000000000000f
(XEN)  000007e520000-000007e55ffff type=4 attr=000000000000000f
(XEN)  000007e560000-00000850e6fff type=7 attr=000000000000000f
(XEN)  00000850e7000-000008539efff type=1 attr=000000000000000f
(XEN)  000008539f000-0000086489fff type=4 attr=000000000000000f
(XEN)  000008648a000-000008648afff type=10 attr=000000000000000f
(XEN)  000008648b000-00000864b4fff type=6 attr=800000000000000f
(XEN)  00000864b5000-000008650ffff type=4 attr=000000000000000f
(XEN)  0000086510000-0000086517fff type=7 attr=000000000000000f
(XEN)  0000086518000-0000086518fff type=2 attr=000000000000000f
(XEN)  0000086519000-00000881fffff type=7 attr=000000000000000f
(XEN)  0000088200000-00000885e8fff type=2 attr=000000000000000f
(XEN)  00000885e9000-000008bc23fff type=4 attr=000000000000000f
(XEN)  000008bc24000-000008bec0fff type=7 attr=000000000000000f
(XEN)  000008bec1000-000008c223fff type=3 attr=000000000000000f
(XEN)  000008c224000-000008c527fff type=0 attr=000000000000000f
(XEN)  000008c528000-000008c735fff type=7 attr=000000000000000f
(XEN)  000008c736000-000008cea6fff type=10 attr=000000000000000f
(XEN)  000008cea7000-000008d29ffff type=6 attr=800000000000000f
(XEN)  000008d2a0000-000008d2fefff type=5 attr=800000000000000f
(XEN)  000008d2ff000-000008d2fffff type=4 attr=000000000000000f
(XEN)  0000100000000-000016dffffff type=7 attr=000000000000000f
(XEN)  000008d300000-000008d3fffff type=0 attr=0000000000000000
(XEN)  00000e0000000-00000efffffff type=11 attr=8000000000000001
(XEN)  00000fe000000-00000fe010fff type=11 attr=8000000000000001
(XEN)  00000fec00000-00000fec00fff type=11 attr=8000000000000001
(XEN)  00000fee00000-00000fee00fff type=11 attr=8000000000000001
(XEN)  00000ff000000-00000ffffffff type=11 attr=8000000000000001
(XEN) alt table ffff82d0804791b0 -> ffff82d0804871cc
(XEN) spurious 8259A interrupt: IRQ7.
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB
(XEN) Intel VT-d iommu 1 supported page sizes: 4kB, 2MB, 1GB
(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 Posted Interrupt not enabled.
(XEN) Intel VT-d Shared EPT tables enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping enabled
(XEN) nr_sockets: 1
(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=0 pin2=0
(XEN) TSC_DEADLINE disabled due to Errata; please update microcode to version 0xb2 (or later)
(XEN) Allocated console ring of 32 KiB.
(XEN) mwait-idle: MWAIT substates: 0x11142120
(XEN) mwait-idle: v0.4.1 model 0x4e
(XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN)  - VMCS shadowing
(XEN)  - VM Functions
(XEN)  - Virtualisation Exceptions
(XEN)  - Page Modification Logging
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) alt table ffff82d0804791b0 -> ffff82d0804871cc
(XEN) Brought up 2 CPUs
(XEN) Parked 2 CPUs
(XEN) Adding cpu 0 to runqueue 0
(XEN)  First cpu on runqueue, activating
(XEN) Adding cpu 2 to runqueue 0
(XEN) Running stub recovery selftests...
(XEN) traps.c:1589: GPF (0000): ffff82d0bffff041 [ffff82d0bffff041] -> ffff82d0803883f3
(XEN) traps.c:784: Trap 12: ffff82d0bffff040 [ffff82d0bffff040] -> ffff82d0803883f3
(XEN) traps.c:1123: Trap 3: ffff82d0bffff041 [ffff82d0bffff041] -> ffff82d0803883f3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) Dom0 has maximum 312 PIRQs
(XEN) NX (Execute Disable) protection active
(XEN) *** Building a PV Dom0 ***
(XEN) ELF: phdr: paddr=0x1000000 memsz=0x1102000
(XEN) ELF: phdr: paddr=0x2200000 memsz=0x488000
(XEN) ELF: phdr: paddr=0x2688000 memsz=0x23118
(XEN) ELF: phdr: paddr=0x26ac000 memsz=0x380000
(XEN) ELF: memory: 0x1000000 -> 0x2a2c000
(XEN) ELF: note: GUEST_OS = "linux"
(XEN) ELF: note: GUEST_VERSION = "2.6"
(XEN) ELF: note: XEN_VERSION = "xen-3.0"
(XEN) ELF: note: VIRT_BASE = 0xffffffff80000000
(XEN) ELF: note: INIT_P2M = 0x8000000000
(XEN) ELF: note: ENTRY = 0xffffffff826ac180
(XEN) ELF: note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) ELF: note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
(XEN) ELF: note: SUPPORTED_FEATURES = 0x8801
(XEN) ELF: note: PAE_MODE = "yes"
(XEN) ELF: note: LOADER = "generic"
(XEN) ELF: note: unknown (0xd)
(XEN) ELF: note: SUSPEND_CANCEL = 0x1
(XEN) ELF: note: MOD_START_PFN = 0x1
(XEN) ELF: note: HV_START_LOW = 0xffff800000000000
(XEN) ELF: note: PADDR_OFFSET = 0
(XEN) ELF: note: PHYS32_ENTRY = 0x1000340
(XEN) ELF: Found PVH image
(XEN) ELF: addresses:
(XEN)     virt_base        = 0xffffffff80000000
(XEN)     elf_paddr_offset = 0x0
(XEN)     virt_offset      = 0xffffffff80000000
(XEN)     virt_kstart      = 0xffffffff81000000
(XEN)     virt_kend        = 0xffffffff82a2c000
(XEN)     virt_entry       = 0xffffffff826ac180
(XEN)     p2m_base         = 0x8000000000
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2a2c000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000164000000->0000000168000000 (245760 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff82a2c000
(XEN)  Init. ramdisk: 0000000000000000->0000000000000000
(XEN)  Phys-Mach map: 0000008000000000->0000008000200000
(XEN)  Start info:    ffffffff82a2c000->ffffffff82a2c4b8
(XEN)  Xenstore ring: 0000000000000000->0000000000000000
(XEN)  Console ring:  0000000000000000->0000000000000000
(XEN)  Page tables:   ffffffff82a2d000->ffffffff82a46000
(XEN)  Boot stack:    ffffffff82a46000->ffffffff82a47000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82c00000
(XEN)  ENTRY ADDRESS: ffffffff826ac180
(XEN) Dom0 has maximum 1 VCPUs
(XEN) ELF: phdr 0 at 0xffffffff81000000 -> 0xffffffff82102000
(XEN) ELF: phdr 1 at 0xffffffff82200000 -> 0xffffffff82688000
(XEN) ELF: phdr 2 at 0xffffffff82688000 -> 0xffffffff826ab118
(XEN) ELF: phdr 3 at 0xffffffff826ac000 -> 0xffffffff8281b000
(XEN) Bogus DMIBAR 0xfed18001 on 0000:00:00.0
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Scrubbing Free RAM in background
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input)
(XEN) Freed 540kB init memory
(XEN) emul-priv-op.c:1113:d0v0 Domain attempted WRMSR 0000001b from 0x00000000fee00d00 to 0x00000000fee00100
(XEN) emul-priv-op.c:1113:d0v0 Domain attempted WRMSR 0000001b from 0x00000000fee00d00 to 0x00000000fee00900
(XEN) d0: Forcing write emulation on MFNs e0000-effff
(XEN) Bogus DMIBAR 0xfed18001 on 0000:00:00.0
(XEN) PCI add device 0000:00:00.0
(XEN) PCI add device 0000:00:02.0
(XEN) PCI add device 0000:00:08.0
(XEN) PCI add device 0000:00:14.0
(XEN) PCI add device 0000:00:14.2
(XEN) PCI add device 0000:00:16.0
(XEN) PCI add device 0000:00:17.0
(XEN) PCI add device 0000:00:1c.0
(XEN) PCI add device 0000:00:1c.5
(XEN) PCI add device 0000:00:1f.0
(XEN) PCI add device 0000:00:1f.2
(XEN) PCI add device 0000:00:1f.3
(XEN) PCI add device 0000:00:1f.4
(XEN) PCI add device 0000:00:1f.6
(XEN) PCI add device 0000:01:00.0
(XEN) PCI add device 0000:02:00.0
(XEN) d0: Forcing read-only access to MFN fed00

[-- Attachment #3: info.txt --]
[-- Type: text/plain, Size: 1411 bytes --]

host                   : linuxkit-000babe4d0c5
release                : 4.19.5-linuxkit
version                : #1 SMP Fri Nov 15 01:33:57 UTC 2019
machine                : x86_64
nr_cpus                : 2
max_cpu_id             : 3
nr_nodes               : 1
cores_per_socket       : 2
threads_per_core       : 1
cpu_mhz                : 2496.180
hw_caps                : bfebfbff:76faf3ff:2c100800:00000121:0000000f:009c6fbf:00000000:00000100
virt_caps              : pv hvm hvm_directio pv_directio hap shadow iommu_hap_pt_share
total_memory           : 4003
free_memory            : 2911
sharing_freed_memory   : 0
sharing_used_memory    : 0
outstanding_claims     : 0
free_cpus              : 0
xen_major              : 4
xen_minor              : 13
xen_extra              : .0-rc
xen_version            : 4.13.0-rc
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler          : credit2
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : 
xen_commandline        : dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
cc_compiler            : gcc (Alpine 6.4.0) 6.4.0
cc_compile_by          : 
cc_compile_domain      : 
cc_compile_date        : Thu Nov 14 06:43:01 UTC 2019
build_id               : 3cf9f737e7ebc3c92024f33583302bdacd36b883
xend_config_format     : 4

[-- Attachment #4: Type: text/plain, Size: 157 bytes --]

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

Re: [Xen-devel] Likely regression in efi=no-rs option

[Rich Persaud]

I don't know if there's a change in efi=no-rs behavior, but some EFI fixes were merged on 10/25, which (on some machines) have reduced the need to disable UEFI runtime services to work around non-spec UEFI firmware.  This should increase hardware compatibility with Xen.  Of course, there could still be other reasons to disable UEFI runtime services.

Could you try booting the affected systems with efi=rs?

Rich

> On Nov 16, 2019, at 00:27, Roman Shaposhnik <roman@zededa.com> wrote:
> 
> Hi!
> 
> as I've reported earlier -- part of my testing of Xen 4.13 RC2 failed
> in a massive way with Dom0 never coming up. I've traced that problem
> to the option that we're using to boot Xen:
>    efi=no-rs
> We've been using this option for quite sometime and Xen 4.13 RC2
> is the first one that seems to make Dom0 boot fail with this option
> present (note that RC1 was fine).
> 
> I was wondering whether there were any changes in the areas related
> to UEFI in Xen that may have triggered this.
> 
> Here's the boot line that works with RC2:
>    dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
> adding efi=no-rs make Dom0 boot process fail:
>    efi=no-rs dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
> 
> Attaching xl info and dmesg just in case
> 
> Thanks,
> Roman.
> <dmesg.txt>
> <info.txt>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] Likely regression in efi=no-rs option

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 1304 bytes --]

On Fri, Nov 15, 2019 at 09:24:38PM -0800, Roman Shaposhnik wrote:
> Hi!
> 
> as I've reported earlier -- part of my testing of Xen 4.13 RC2 failed
> in a massive way with Dom0 never coming up. I've traced that problem
> to the option that we're using to boot Xen:
>     efi=no-rs
> We've been using this option for quite sometime and Xen 4.13 RC2
> is the first one that seems to make Dom0 boot fail with this option
> present (note that RC1 was fine).
> 
> I was wondering whether there were any changes in the areas related
> to UEFI in Xen that may have triggered this.
> 
> Here's the boot line that works with RC2:
>     dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
> adding efi=no-rs make Dom0 boot process fail:
>     efi=no-rs dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin smt=false

As Rich already said, there was indeed some related changes, that should
make efi=no-rs not needed as an workaround on many machines.
But also it looks like the "efi: use directmap to access runtime
services table" commit broke efi=no-rs case. I'll send the fix shortly.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: [Xen-devel] Likely regression in efi=no-rs option

[Roman Shaposhnik]

[-- Attachment #1.1: Type: text/plain, Size: 1590 bytes --]

Rich, Marek, thanks a million for quick replies -- I'll try your
suggestions tomorrow in my lab.

Thanks,
Roman.

On Sat, Nov 16, 2019 at 3:07 PM Marek Marczykowski-Górecki <
marmarek@invisiblethingslab.com> wrote:

> On Fri, Nov 15, 2019 at 09:24:38PM -0800, Roman Shaposhnik wrote:
> > Hi!
> >
> > as I've reported earlier -- part of my testing of Xen 4.13 RC2 failed
> > in a massive way with Dom0 never coming up. I've traced that problem
> > to the option that we're using to boot Xen:
> >     efi=no-rs
> > We've been using this option for quite sometime and Xen 4.13 RC2
> > is the first one that seems to make Dom0 boot fail with this option
> > present (note that RC1 was fine).
> >
> > I was wondering whether there were any changes in the areas related
> > to UEFI in Xen that may have triggered this.
> >
> > Here's the boot line that works with RC2:
> >     dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
> > adding efi=no-rs make Dom0 boot process fail:
> >     efi=no-rs dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin
> smt=false
>
> As Rich already said, there was indeed some related changes, that should
> make efi=no-rs not needed as an workaround on many machines.
> But also it looks like the "efi: use directmap to access runtime
> services table" commit broke efi=no-rs case. I'll send the fix shortly.
>
> --
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
>

[-- Attachment #1.2: Type: text/html, Size: 2105 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: [Xen-devel] Likely regression in efi=no-rs option

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 500 bytes --]

On Sun, Nov 17, 2019 at 05:06:11PM -0800, Roman Shaposhnik wrote:
> Rich, Marek, thanks a million for quick replies -- I'll try your
> suggestions tomorrow in my lab.

To make use of the change, enable "EFI: call SetVirtualAddressMap()" in
menuconfig (Common Features), visible only with XEN_CONFIG_EXPERT=y.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: [Xen-devel] Likely regression in efi=no-rs option

[Roman Shaposhnik]

Ok, to sum up -- there's definitely a pretty major regression on all
this hardware with Xen 4.13 RC2:
     https://www.dell.com/en-us/work/shop/gateways-embedded-computing/sc/gateways-embedded-pcs/edge-gateway?~ck=bt

Without efi=no-rs option Xen panics on boot (sorry for attaching the
screenshot -- I know it is not super helpful but it gets the point
across)

With efi=no-rs Xen boots fine, but Dom0 can't come up.

And, once again, this is clearly a regression from RC1 (just verified).

Thanks,
Roman.

On Sat, Nov 16, 2019 at 12:47 PM Rich Persaud <persaur@gmail.com> wrote:
>
> I don't know if there's a change in efi=no-rs behavior, but some EFI fixes were merged on 10/25, which (on some machines) have reduced the need to disable UEFI runtime services to work around non-spec UEFI firmware.  This should increase hardware compatibility with Xen.  Of course, there could still be other reasons to disable UEFI runtime services.
>
> Could you try booting the affected systems with efi=rs?
>
> Rich
>
> > On Nov 16, 2019, at 00:27, Roman Shaposhnik <roman@zededa.com> wrote:
> >
> > Hi!
> >
> > as I've reported earlier -- part of my testing of Xen 4.13 RC2 failed
> > in a massive way with Dom0 never coming up. I've traced that problem
> > to the option that we're using to boot Xen:
> >    efi=no-rs
> > We've been using this option for quite sometime and Xen 4.13 RC2
> > is the first one that seems to make Dom0 boot fail with this option
> > present (note that RC1 was fine).
> >
> > I was wondering whether there were any changes in the areas related
> > to UEFI in Xen that may have triggered this.
> >
> > Here's the boot line that works with RC2:
> >    dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
> > adding efi=no-rs make Dom0 boot process fail:
> >    efi=no-rs dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
> >
> > Attaching xl info and dmesg just in case
> >
> > Thanks,
> > Roman.
> > <dmesg.txt>
> > <info.txt>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xenproject.org
> > https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] Likely regression in efi=no-rs option

[Roman Shaposhnik]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

On Sun, Nov 17, 2019 at 5:27 PM Marek Marczykowski-Górecki
<marmarek@invisiblethingslab.com> wrote:
>
> On Sun, Nov 17, 2019 at 05:06:11PM -0800, Roman Shaposhnik wrote:
> > Rich, Marek, thanks a million for quick replies -- I'll try your
> > suggestions tomorrow in my lab.
>
> To make use of the change, enable "EFI: call SetVirtualAddressMap()" in
> menuconfig (Common Features), visible only with XEN_CONFIG_EXPERT=y.

Hm. It seems I had trouble building with your patch. Is there any chance I can
simply force it from the make side?

Or to ask it differently, if I simply do make defconfig what can I just add that
option to the config file?

Thanks,
Roman.

[-- Attachment #2: 20191118_201301.jpg --]
[-- Type: image/jpeg, Size: 4685177 bytes --]

[-- Attachment #3: Type: text/plain, Size: 157 bytes --]

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

Re: [Xen-devel] Likely regression in efi=no-rs option

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 1105 bytes --]

On Mon, Nov 18, 2019 at 11:15:43PM -0800, Roman Shaposhnik wrote:
> On Sun, Nov 17, 2019 at 5:27 PM Marek Marczykowski-Górecki
> <marmarek@invisiblethingslab.com> wrote:
> >
> > On Sun, Nov 17, 2019 at 05:06:11PM -0800, Roman Shaposhnik wrote:
> > > Rich, Marek, thanks a million for quick replies -- I'll try your
> > > suggestions tomorrow in my lab.
> >
> > To make use of the change, enable "EFI: call SetVirtualAddressMap()" in
> > menuconfig (Common Features), visible only with XEN_CONFIG_EXPERT=y.
> 
> Hm. It seems I had trouble building with your patch. Is there any chance I can
> simply force it from the make side?
> 
> Or to ask it differently, if I simply do make defconfig what can I just add that
> option to the config file?

You need to enable XEN_CONFIG_EXPERT=y anyway, just like this:

    export XEN_CONFIG_EXPERT=y

Then, the option is CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: [Xen-devel] Likely regression in efi=no-rs option

[Roman Shaposhnik]

On Mon, Nov 18, 2019 at 11:31 PM Rich Persaud <persaur@gmail.com> wrote:
>
> On Nov 19, 2019, at 02:13, Roman Shaposhnik <roman@zededa.com> wrote:
> >
> > Ok, to sum up -- there's definitely a pretty major regression on all
> > this hardware with Xen 4.13 RC2:
> >   https://www.dell.com/en-us/work/shop/gateways-embedded-computing/sc/gateways-embedded-pcs/edge-gateway?~ck=bt
> >
> > Without efi=no-rs option Xen panics on boot (sorry for attaching the
> > screenshot -- I know it is not super helpful but it gets the point
> > across)
>
> I don't think the screenshot came through..

Somehow I managed to attach it to my reply to Marek ;-)
    https://lists.xenproject.org/archives/html/xen-devel/2019-11/jpgQ5AktZzvAH.jpg

> By "without efi=no-rs" do you mean "efi=rs" or no explicit value for efi on the Xen command line?

No explicit value. Is there a difference? I assumed default (no
explicit value) means efi=rs -- am I mistaken?

> > With efi=no-rs Xen boots fine, but Dom0 can't come up.
>
> Is that with RC2, or RC2 + the recent patch from Marek for efi=no-rs?

Just vanilla RC2 -- like I said -- I think I have trouble building his
with patch (see my reply to him).

>  Any serial logs from dom0 boot?  Can you share the dom0 kernel command line with all options?

Would be happy to share them once I get to the lab (and hopefully by
that time I can figure out how to build with Marek's patch).

Thanks,
Roman.

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

Re: [Xen-devel] Likely regression in efi=no-rs option

[Rich Persaud]

On Nov 19, 2019, at 02:13, Roman Shaposhnik <roman@zededa.com> wrote:
> 
> Ok, to sum up -- there's definitely a pretty major regression on all
> this hardware with Xen 4.13 RC2:
>   https://www.dell.com/en-us/work/shop/gateways-embedded-computing/sc/gateways-embedded-pcs/edge-gateway?~ck=bt
> 
> Without efi=no-rs option Xen panics on boot (sorry for attaching the
> screenshot -- I know it is not super helpful but it gets the point
> across)

I don't think the screenshot came through..

By "without efi=no-rs" do you mean "efi=rs" or no explicit value for efi on the Xen command line?

> With efi=no-rs Xen boots fine, but Dom0 can't come up.

Is that with RC2, or RC2 + the recent patch from Marek for efi=no-rs?  Any serial logs from dom0 boot?  Can you share the dom0 kernel command line with all options?

Thanks,
Rich

> And, once again, this is clearly a regression from RC1 (just verified).
> 
> Thanks,
> Roman.
> 
>>>> On Sat, Nov 16, 2019 at 12:47 PM Rich Persaud <persaur@gmail.com> wrote:
>> I don't know if there's a change in efi=no-rs behavior, but some EFI fixes were merged on 10/25, which (on some machines) have reduced the need to disable UEFI runtime services to work around non-spec UEFI firmware.  This should increase hardware compatibility with Xen.  Of course, there could still be other reasons to disable UEFI runtime services.
>> Could you try booting the affected systems with efi=rs?
>> Rich
>>>> On Nov 16, 2019, at 00:27, Roman Shaposhnik <roman@zededa.com> wrote:
>>> Hi!
>>> as I've reported earlier -- part of my testing of Xen 4.13 RC2 failed
>>> in a massive way with Dom0 never coming up. I've traced that problem
>>> to the option that we're using to boot Xen:
>>> efi=no-rs
>>> We've been using this option for quite sometime and Xen 4.13 RC2
>>> is the first one that seems to make Dom0 boot fail with this option
>>> present (note that RC1 was fine).
>>> I was wondering whether there were any changes in the areas related
>>> to UEFI in Xen that may have triggered this.
>>> Here's the boot line that works with RC2:
>>> dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
>>> adding efi=no-rs make Dom0 boot process fail:
>>> efi=no-rs dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
>>> Attaching xl info and dmesg just in case
>>> Thanks,
>>> Roman.
>>> <dmesg.txt>
>>> <info.txt>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xenproject.org
>>> https://lists.xenproject.org/mailman/listinfo/xen-devel

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