* Xen 4.14.0 is busted on Dell 300x IoT Gateways
@ 2020-08-18 22:09 Roman Shaposhnik
2020-08-18 22:20 ` Andrew Cooper
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Roman Shaposhnik @ 2020-08-18 22:09 UTC (permalink / raw)
To: Xen-devel; +Cc: Roger Pau Monné, Andrew Cooper, Paul Durrant, Jan Beulich
[-- Attachment #1.1: Type: text/plain, Size: 487 bytes --]
Hi!
first things first -- booting on those devices have always
required efi=no-rs -- but it seems that Xen 4.14 is now
busted at a more fundamental level. I'm attaching two
boot sequences (one with kernel 4.19.5 and one with 5.4.51)
in the hopes that this may provide some clues right away.
Any help would be greatly appreciated!
Oh, and finally it appears that this is NOT a regression from
Xen 4.13 -- it fails the same way. I haven't tried Xen's earlier
than that.
Thanks,
Roman.
[-- Attachment #1.2: Type: text/html, Size: 723 bytes --]
[-- Attachment #2: 4.txt --]
[-- Type: text/plain, Size: 24553 bytes --]
Xen 4.14.0
(XEN) Xen version 4.14.0 (@) (gcc (Alpine 6.4.0) 6.4.0) debug=n Sat Jul 25 23:45:43 UTC 2020
(XEN) Latest ChangeSet:
(XEN) Bootloader: GRUB 2.03
(XEN) Command line: com1=115200,8n1 console=com1 efi=no-rs dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin
(XEN) Xen image load base address: 0x71000000
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) Disc information:
(XEN) Found 0 MBR signatures
(XEN) Found 1 EDD information structures
(XEN) EFI RAM map:
(XEN) [0000000000000000, 000000000003efff] (usable)
(XEN) [000000000003f000, 000000000003ffff] (ACPI NVS)
(XEN) [0000000000040000, 000000000009ffff] (usable)
(XEN) [0000000000100000, 000000001fffffff] (usable)
(XEN) [0000000020000000, 00000000200fffff] (reserved)
(XEN) [0000000020100000, 0000000076ccafff] (usable)
(XEN) [0000000076ccb000, 0000000076d42fff] (reserved)
(XEN) [0000000076d43000, 0000000076d53fff] (ACPI data)
(XEN) [0000000076d54000, 00000000772ddfff] (ACPI NVS)
(XEN) [00000000772de000, 00000000775f4fff] (reserved)
(XEN) [00000000775f5000, 00000000775f5fff] (usable)
(XEN) [00000000775f6000, 0000000077637fff] (reserved)
(XEN) [0000000077638000, 00000000789e4fff] (usable)
(XEN) [00000000789e5000, 0000000078ff9fff] (reserved)
(XEN) [0000000078ffa000, 0000000078ffffff] (usable)
(XEN) [00000000e0000000, 00000000efffffff] (reserved)
(XEN) [00000000fec00000, 00000000fec00fff] (reserved)
(XEN) [00000000fed01000, 00000000fed01fff] (reserved)
(XEN) [00000000fed03000, 00000000fed03fff] (reserved)
(XEN) [00000000fed08000, 00000000fed08fff] (reserved)
(XEN) [00000000fed0c000, 00000000fed0ffff] (reserved)
(XEN) [00000000fed1c000, 00000000fed1cfff] (reserved)
(XEN) [00000000fee00000, 00000000fee00fff] (reserved)
(XEN) [00000000fef00000, 00000000feffffff] (reserved)
(XEN) [00000000ff900000, 00000000ffffffff] (reserved)
(XEN) System RAM: 1919MB (1965176kB)
(XEN) ACPI: RSDP 76D46000, 0024 (r2 DELL)
(XEN) ACPI: XSDT 76D46088, 0094 (r1 DELL AS09 1072009 AMI 10013)
(XEN) ACPI: FACP 76D52560, 010C (r5 DELL AS09 1072009 AMI 10013)
(XEN) ACPI: DSDT 76D461B0, C3AF (r2 DELL AS09 1072009 INTL 20120913)
(XEN) ACPI: FACS 772DDE80, 0040
(XEN) ACPI: APIC 76D52670, 0068 (r3 DELL AS09 1072009 AMI 10013)
(XEN) ACPI: FPDT 76D526D8, 0044 (r1 DELL AS09 1072009 AMI 10013)
(XEN) ACPI: FIDT 76D52720, 009C (r1 DELL AS09 1072009 AMI 10013)
(XEN) ACPI: MCFG 76D527C0, 003C (r1 DELL AS09 1072009 MSFT 97)
(XEN) ACPI: LPIT 76D52800, 0104 (r1 DELL AS09 3 VLV2 100000D)
(XEN) ACPI: HPET 76D52908, 0038 (r1 DELL AS09 1072009 AMI. 5)
(XEN) ACPI: SSDT 76D52940, 0763 (r1 DELL AS09 3000 INTL 20061109)
(XEN) ACPI: SSDT 76D530A8, 0290 (r1 DELL AS09 3000 INTL 20061109)
(XEN) ACPI: SSDT 76D53338, 017A (r1 DELL AS09 3000 INTL 20061109)
(XEN) ACPI: UEFI 76D534B8, 0042 (r1 DELL AS09 0 0)
(XEN) ACPI: CSRT 76D53500, 014C (r0 DELL AS09 5 INTL 20120624)
(XEN) ACPI: TPM2 76D53650, 0034 (r3 Tpm2Tabl 1 AMI 0)
(XEN) ACPI: SSDT 76D53688, 00C9 (r1 MSFT RHPROXY 1 INTL 20120913)
(XEN) Domain heap initialised
(XEN) ACPI: 32/64X FACS address mismatch in FADT - 772dde80/0000000000000000, using 32
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-86
(XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
(XEN) CPU0: 400..1000 MHz
(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) Support for HVM VMs: RSB
(XEN) Support for PV VMs: RSB
(XEN) XPTI (64-bit PV only): Dom0 enabled, DomU enabled (without PCID)
(XEN) PV L1TF shadowing: Dom0 disabled, DomU disabled
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN) Disabling HPET for being unreliable
(XEN) Platform timer is 3.580MHz ACPI PM Timer
(XEN) Detected 1333.410 MHz processor.
(XEN) I/O virtualisation disabled
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using new ACK method
(XEN) Allocated console ring of 16 KiB.
(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) - VM Functions
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB
(XEN) Brought up 2 CPUs
(XEN) Scheduling granularity: cpu, 1 CPU per sched-resource
(XEN) Dom0 has maximum 295 PIRQs
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2a2c000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 000000006c000000->0000000070000000 (240976 pages to be allocated)
(XEN) Init. ramdisk: 0000000075950000->0000000076bffc5c
(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: ffffffff82702180
(XEN) Dom0 has maximum 1 VCPUs
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Scrubbing Free RAM in background
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input)
(XEN) Freed 560kB init memory
mapping kernel into physical memory
about to get started...
[ 0.000000] Could not determine UEFI Secure Boot status.
[ 0.000000] Linux version 4.19.5-linuxkit (root@f3586cd3d42c) (gcc version 8.3.0 (Alpine 8.3.0)) #1 SMP Sat Aug 15 18:51:14 UTC 2020
[ 0.000000] Command line: console=hvc0 root=(hd0,gpt1)/rootfs.img dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin eve_mem=650M,max:650M eve_max_vcpus=1 ctrd_mem=300M,max:300M ctrd_max_vcpus=1 rootdelay=3 setup_loops eve_installer
[ 0.000000] x86/fpu: x87 FPU will use FXSAVE
[ 0.000000] Released 0 page(s)
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] Xen: [mem 0x0000000000000000-0x000000000003efff] usable
[ 0.000000] Xen: [mem 0x000000000003f000-0x000000000003ffff] ACPI NVS
[ 0.000000] Xen: [mem 0x0000000000040000-0x000000000009ffff] usable
[ 0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[ 0.000000] Xen: [mem 0x0000000000100000-0x000000001fffffff] usable
[ 0.000000] Xen: [mem 0x0000000020000000-0x00000000200fffff] reserved
[ 0.000000] Xen: [mem 0x0000000020100000-0x0000000040160fff] usable
[ 0.000000] Xen: [mem 0x0000000040161000-0x0000000076ccafff] unusable
[ 0.000000] Xen: [mem 0x0000000076ccb000-0x0000000076d42fff] reserved
[ 0.000000] Xen: [mem 0x0000000076d43000-0x0000000076d53fff] ACPI data
[ 0.000000] Xen: [mem 0x0000000076d54000-0x00000000772ddfff] ACPI NVS
[ 0.000000] Xen: [mem 0x00000000772de000-0x00000000775f4fff] reserved
[ 0.000000] Xen: [mem 0x00000000775f5000-0x00000000775f5fff] unusable
[ 0.000000] Xen: [mem 0x00000000775f6000-0x0000000077637fff] reserved
[ 0.000000] Xen: [mem 0x0000000077638000-0x00000000789e4fff] unusable
[ 0.000000] Xen: [mem 0x00000000789e5000-0x0000000078ff9fff] reserved
[ 0.000000] Xen: [mem 0x0000000078ffa000-0x0000000078ffffff] unusable
[ 0.000000] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[ 0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[ 0.000000] Xen: [mem 0x00000000fed01000-0x00000000fed01fff] reserved
[ 0.000000] Xen: [mem 0x00000000fed03000-0x00000000fed03fff] reserved
[ 0.000000] Xen: [mem 0x00000000fed08000-0x00000000fed08fff] reserved
[ 0.000000] Xen: [mem 0x00000000fed0c000-0x00000000fed0ffff] reserved
[ 0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed1cfff] reserved
[ 0.000000] Xen: [mem 0x00000000fee00000-0x00000000feffffff] reserved
[ 0.000000] Xen: [mem 0x00000000ff900000-0x00000000ffffffff] reserved
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] efi: EFI v2.40 by UNKNOWN
[ 0.000000] efi: ACPI=0x76d46000 ACPI 2.0=0x76d46000 SMBIOS=0xf05b0 ESRT=0x7748b598 MPS=0xfd640
[ 0.000000] SMBIOS 3.0 present.
[ 0.000000] DMI: Dell Inc. Edge Gateway 3001/0DY2CV, BIOS 01.00.01 05/16/2017
[ 0.000000] Hypervisor detected: Xen PV
[ 0.000491] tsc: Detected 1333.410 MHz processor
[ 0.001253] last_pfn = 0x40161 max_arch_pfn = 0x400000000
[ 0.001258] Disabled
[ 0.001263] x86/PAT: MTRRs disabled, skipping PAT initialization too.
[ 0.001276] x86/PAT: Configuration [0-7]: WB WT UC- UC WC WP UC UC
[ 0.001384] Kernel/User page tables isolation: disabled on XEN PV.
[ 0.653685] Secure boot could not be determined
[ 0.653697] RAMDISK: [mem 0x04000000-0x052affff]
[ 0.657485] ACPI: Early table checksum verification disabled
[ 0.657520] ACPI: RSDP 0x0000000076D46000 000024 (v02 DELL )
[ 0.657551] ACPI: XSDT 0x0000000076D46088 000094 (v01 DELL AS09 01072009 AMI 00010013)
[ 0.657612] ACPI: FACP 0x0000000076D52560 00010C (v05 DELL AS09 01072009 AMI 00010013)
[ 0.657684] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 128/32 (20180810/tbfadt-569)
[ 0.657723] ACPI: DSDT 0x0000000076D461B0 00C3AF (v02 DELL AS09 01072009 INTL 20120913)
[ 0.657762] ACPI: FACS 0x00000000772DDE80 000040
[ 0.657799] ACPI: APIC 0x0000000076D52670 000068 (v03 DELL AS09 01072009 AMI 00010013)
[ 0.657838] ACPI: FPDT 0x0000000076D526D8 000044 (v01 DELL AS09 01072009 AMI 00010013)
[ 0.657877] ACPI: FIDT 0x0000000076D52720 00009C (v01 DELL AS09 01072009 AMI 00010013)
[ 0.657915] ACPI: MCFG 0x0000000076D527C0 00003C (v01 DELL AS09 01072009 MSFT 00000097)
[ 0.657954] ACPI: LPIT 0x0000000076D52800 000104 (v01 DELL AS09 00000003 VLV2 0100000D)
[ 0.657992] ACPI: HPET 0x0000000076D52908 000038 (v01 DELL AS09 01072009 AMI. 00000005)
[ 0.658031] ACPI: SSDT 0x0000000076D52940 000763 (v01 DELL AS09 00003000 INTL 20061109)
[ 0.658069] ACPI: SSDT 0x0000000076D530A8 000290 (v01 DELL AS09 00003000 INTL 20061109)
[ 0.658108] ACPI: SSDT 0x0000000076D53338 00017A (v01 DELL AS09 00003000 INTL 20061109)
[ 0.658147] ACPI: UEFI 0x0000000076D534B8 000042 (v01 DELL AS09 00000000 00000000)
[ 0.658185] ACPI: CSRT 0x0000000076D53500 00014C (v00 DELL AS09 00000005 INTL 20120624)
[ 0.658223] ACPI: TPM2 0x0000000076D53650 000034 (v03 Tpm2Tabl 00000001 AMI 00000000)
[ 0.658261] ACPI: SSDT 0x0000000076D53688 0000C9 (v01 MSFT RHPROXY 00000001 INTL 20120913)
[ 0.658356] Setting APIC routing to Xen PV.
[ 0.673157] Zone ranges:
[ 0.673166] DMA [mem 0x0000000000001000-0x0000000000ffffff]
[ 0.673174] DMA32 [mem 0x0000000001000000-0x0000000040160fff]
[ 0.673181] Normal empty
[ 0.673187] Movable zone start for each node
[ 0.673191] Early memory node ranges
[ 0.673197] node 0: [mem 0x0000000000001000-0x000000000003efff]
[ 0.673202] node 0: [mem 0x0000000000040000-0x000000000009ffff]
[ 0.673208] node 0: [mem 0x0000000000100000-0x000000001fffffff]
[ 0.673213] node 0: [mem 0x0000000020100000-0x0000000040160fff]
[ 0.675279] Reserved but unavailable: 32769 pages
[ 0.675287] Initmem setup node 0 [mem 0x0000000000001000-0x0000000040160fff]
[ 0.692350] p2m virtual area at (____ptrval____), size is 40000000
[ 1.307971] Remapped 353 page(s)
[ 1.308021] x86/hpet: Will disable the HPET for this platform because it's not reliable
[ 1.309328] ACPI: PM-Timer IO Port: 0x408
[ 1.309420] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[ 1.309427] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[ 1.309481] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-86
[ 1.309506] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 1.309516] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 1.309559] Using ACPI (MADT) for SMP configuration information
[ 1.309575] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[ 1.309599] smpboot: Allowing 2 CPUs, 0 hotplug CPUs
[ 1.309691] [mem 0x79000000-0xdfffffff] available for PCI devices
[ 1.309703] Booting paravirtualized kernel on Xen
[ 1.309709] Xen version: 4.14.0 (preserve-AD)
[ 1.309717] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 1.727758] random: get_random_bytes called from start_kernel+0x91/0x4bd with crng_init=0
[ 1.727792] setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:2 nr_node_ids:1
[ 1.728699] percpu: Embedded 45 pages/cpu @(____ptrval____) s143704 r8192 d32424 u1048576
[ 1.728881] Built 1 zonelists, mobility grouping on. Total pages: 258020
[ 1.728891] Kernel command line: console=hvc0 root=(hd0,gpt1)/rootfs.img dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin eve_mem=650M,max:650M eve_max_vcpus=1 ctrd_mem=300M,max:300M ctrd_max_vcpus=1 rootdelay=3 setup_loops eve_installer
[ 1.729976] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[ 1.730186] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[ 1.821626] software IO TLB: mapped [mem 0x3a600000-0x3e600000] (64MB)
[ 1.846059] Memory: 912164K/1048572K available (12312K kernel code, 1716K rwdata, 3404K rodata, 1664K init, 1520K bss, 136408K reserved, 0K cma-reserved)
[ 1.846329] ftrace: allocating 47361 entries in 186 pages
[ 1.900040] rcu: Hierarchical RCU implementation.
[ 1.900050] rcu: RCU restricting CPUs from NR_CPUS=128 to nr_cpu_ids=1.
[ 1.900055] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[ 1.912470] Using NULL legacy PIC
[ 1.912481] NR_IRQS: 8448, nr_irqs: 256, preallocated irqs: 0
[ 1.912545] xen:events: Using FIFO-based ABI
[ 1.913846] Console: colour dummy device 80x25
[ 1.914595] console [tty0] enabled
[ 1.916296] console [hvc0] enabled
[ 1.916328] ACPI: Core revision 20180810
[ 1.921111] clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 1.921168] installing Xen timer for CPU 0
[ 1.921419] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x13386732d30, max_idle_ns: 440795258156 ns
[ 1.921612] Calibrating delay loop (skipped), value calculated using timer frequency.. 2666.82 BogoMIPS (lpj=13334100)
[ 1.921652] pid_max: default: 32768 minimum: 301
[ 1.922032] Security Framework initialized
[ 1.922055] Yama: becoming mindful.
[ 1.922172] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
[ 1.922205] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes)
[ 1.923018] Last level iTLB entries: 4KB 48, 2MB 0, 4MB 0
[ 1.923048] Last level dTLB entries: 4KB 128, 2MB 16, 4MB 16, 1GB 0
[ 1.923077] Spectre V2 : Mitigation: Full generic retpoline
[ 1.923096] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
[ 2.059190] Freeing SMP alternatives memory: 24K
[ 2.061061] VPMU disabled by hypervisor.
[ 2.061939] Performance Events: unsupported p6 CPU model 55 no PMU driver, software events only.
[ 2.062249] rcu: Hierarchical SRCU implementation.
[ 2.062912] NMI watchdog: Perf NMI watchdog permanently disabled
[ 2.063228] smp: Bringing up secondary CPUs ...
[ 2.063252] smp: Brought up 1 node, 1 CPU
[ 2.063269] smpboot: Max logical packages: 1
[ 2.063890] devtmpfs: initialized
[ 2.064106] x86/mm: Memory block size: 128MB
[ 2.066140] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 2.066191] futex hash table entries: 256 (order: 2, 16384 bytes)
[ 2.066399] pinctrl core: initialized pinctrl subsystem
[ 2.066870] NET: Registered protocol family 16
[ 2.066942] xen:grant_table: Grant tables using version 1 layout
[ 2.067007] Grant table initialized
[ 2.067850] audit: initializing netlink subsys (disabled)
[ 2.068395] audit: type=2000 audit(1325376586.017:1): state=initialized audit_enabled=0 res=1
[ 2.069301] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[ 2.069337] ACPI: bus type PCI registered
[ 2.069802] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[ 2.069842] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[ 2.279608] PCI: Using configuration type 1 for base access
[ 2.290512] cryptd: max_cpu_qlen set to 1000
[ 2.291249] ACPI: Added _OSI(Module Device)
[ 2.291281] ACPI: Added _OSI(Processor Device)
[ 2.291301] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 2.291321] ACPI: Added _OSI(Processor Aggregator Device)
[ 2.291343] ACPI: Added _OSI(Linux-Dell-Video)
[ 2.291363] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[ 2.320060] ACPI: 5 ACPI AML tables successfully acquired and loaded
[ 2.332242] ACPI: Dynamic OEM Table Load:
[ 2.332286] ACPI: SSDT 0xFFFF88803A338800 0002B4 (v01 PmRef Cpu0Ist 00003000 INTL 20061109)
[ 2.333417] ACPI: Dynamic OEM Table Load:
[ 2.333453] ACPI: SSDT 0xFFFF88803A399800 000433 (v01 PmRef Cpu0Cst 00003001 INTL 20061109)
[ 2.337095] ACPI: Interpreter enabled
[ 2.337138] ACPI: (supports S0 S5)
[ 2.337159] ACPI: Using IOAPIC for interrupt routing
[ 2.337298] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 2.338911] ACPI: Enabled 6 GPEs in block 00 to 3F
[ 2.358222] ACPI: Power Resource [USBC] (on)
[ 2.362017] ACPI: Power Resource [PLPE] (on)
[ 2.362922] ACPI: Power Resource [PLPE] (on)
[ 2.377556] ACPI: Power Resource [CLK0] (on)
[ 2.377729] ACPI: Power Resource [CLK1] (on)
[ 2.383252] ACPI: Power Resource [FN00] (off)
[ 2.385299] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 2.385345] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 2.385936] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME]
[ 2.386518] acpi PNP0A08:00: _OSC: OS now controls [PCIeCapability LTR]
[ 2.386547] acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS configuration
[ 2.387258] PCI host bridge to bus 0000:00
[ 2.387287] pci_bus 0000:00: root bus resource [io 0x0070-0x0077]
[ 2.387314] pci_bus 0000:00: root bus resource [io 0x0000-0x006f window]
[ 2.387340] pci_bus 0000:00: root bus resource [io 0x0078-0x0cf7 window]
[ 2.387365] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
[ 2.387391] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[ 2.387420] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff window]
[ 2.387449] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000fffff window]
[ 2.387478] pci_bus 0000:00: root bus resource [mem 0x80000000-0x80336ffe window]
[ 2.387507] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 2.398823] pci 0000:00:1c.0: PCI bridge to [bus 01]
[ 2.401292] pci 0000:00:1c.1: PCI bridge to [bus 02]
[ 2.401661] pci 0000:00:1c.2: PCI bridge to [bus 03]
[ 2.401995] pci 0000:00:1c.3: PCI bridge to [bus 04]
[ 2.403807] ACPI: PCI Interrupt Link [LNKA] (IRQs *3 4 5 6 12 14 15)
[ 2.404087] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 12 14 15)
[ 2.404348] ACPI: PCI Interrupt Link [LNKC] (IRQs *3 4 5 6 12 14 15)
[ 2.404629] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 12 14 15)
[ 2.404888] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 6 12 14 15)
[ 2.405146] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 *5 6 12 14 15)
[ 2.405404] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 12 14 15) *0, disabled.
[ 2.405669] ACPI: PCI Interrupt Link [LNKH] (IRQs *3 4 5 6 12 14 15)
[ 2.407287] ------------[ cut here ]------------
[ 2.407317] kernel BUG at drivers/xen/events/events_base.c:513!
[ 2.407350] invalid opcode: 0000 [#1] SMP NOPTI
[ 2.407372] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.5-linuxkit #1
[ 2.407395] Hardware name: Dell Inc. Edge Gateway 3001/0DY2CV, BIOS 01.00.01 05/16/2017
[ 2.407430] RIP: e030:__startup_pirq+0x38/0x119
[ 2.407452] Code: 83 ec 18 65 48 8b 04 25 28 00 00 00 48 89 44 24 10 31 c0 e8 73 f5 ff ff 89 df 49 89 c4 e8 35 fd ff ff 41 83 7c 24 14 01 74 02 <0f> 0b 41 89 c5 85 c0 0f 85 82 00 00 00 89 df e8 db f7 ff ff bf 02
[ 2.407504] RSP: e02b:ffffc9004002f960 EFLAGS: 00010092
[ 2.407525] RAX: 0000000000000000 RBX: 0000000000000031 RCX: 0000000000000000
[ 2.407550] RDX: ffffffffffffffff RSI: ffffc9004002f918 RDI: ffff888039c00900
[ 2.407576] RBP: ffffffff814f9d64 R08: ffff888039c00ab0 R09: ffff888039c00900
[ 2.407600] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888039853818
[ 2.407625] R13: 0000000000000001 R14: ffff888039888640 R15: ffff888039853818
[ 2.407697] FS: 0000000000000000(0000) GS:ffff88803e600000(0000) knlGS:0000000000000000
[ 2.407725] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2.407747] CR2: 0000000000000000 CR3: 000000000220c000 CR4: 0000000000000660
[ 2.407779] Call Trace:
[ 2.407806] ? _cond_resched+0x20/0x23
[ 2.407829] ? byt_gpio_runtime_resume+0x8/0x8
[ 2.407853] __irq_startup+0x2d/0x59
[ 2.407874] irq_startup+0x41/0xce
[ 2.407895] ? byt_gpio_runtime_resume+0x8/0x8
[ 2.407917] irq_set_chained_handler_and_data+0x50/0x7f
[ 2.407942] gpiochip_set_cascaded_irqchip.isra.31+0x6a/0xba
[ 2.407970] byt_pinctrl_probe+0x4ca/0x4e8
[ 2.407993] platform_drv_probe+0x32/0x73
[ 2.408015] really_probe+0x133/0x27a
[ 2.408036] ? driver_allows_async_probing+0x2c/0x2c
[ 2.408058] driver_probe_device+0x96/0xc6
[ 2.408080] ? driver_allows_async_probing+0x2c/0x2c
[ 2.408101] bus_for_each_drv+0x81/0xa5
[ 2.408123] __device_attach+0xa6/0x11a
[ 2.408143] bus_probe_device+0x2d/0x8c
[ 2.408165] device_add+0x1c1/0x58a
[ 2.408187] platform_device_add+0x140/0x198
[ 2.408210] platform_device_register_full+0xa5/0xfd
[ 2.408236] acpi_create_platform_device+0x1b5/0x205
[ 2.408262] acpi_lpss_create_device+0x36/0x569
[ 2.408287] ? acpi_evaluate_integer+0x52/0x87
[ 2.408311] acpi_bus_attach+0xe5/0x1a3
[ 2.408333] acpi_bus_attach+0x15b/0x1a3
[ 2.408354] acpi_bus_attach+0x15b/0x1a3
[ 2.408376] ? acpi_sleep_init+0x103/0x103
[ 2.408397] ? acpi_sleep_init+0x103/0x103
[ 2.408417] acpi_bus_scan+0x64/0x81
[ 2.408438] acpi_scan_init+0xe7/0x22b
[ 2.408463] ? acpi_sleep_init+0x103/0x103
[ 2.408483] acpi_init+0x2c2/0x31d
[ 2.408506] do_one_initcall+0x86/0x170
[ 2.408529] ? do_early_param+0x8e/0x8e
[ 2.408549] kernel_init_freeable+0x182/0x211
[ 2.408574] ? rest_init+0xa5/0xa5
[ 2.408594] kernel_init+0xa/0xfa
[ 2.408615] ret_from_fork+0x35/0x40
[ 2.408635] Modules linked in:
[ 2.408658] ---[ end trace 7ec97df6f5475598 ]---
[ 2.408681] RIP: e030:__startup_pirq+0x38/0x119
[ 2.408702] Code: 83 ec 18 65 48 8b 04 25 28 00 00 00 48 89 44 24 10 31 c0 e8 73 f5 ff ff 89 df 49 89 c4 e8 35 fd ff ff 41 83 7c 24 14 01 74 02 <0f> 0b 41 89 c5 85 c0 0f 85 82 00 00 00 89 df e8 db f7 ff ff bf 02
[ 2.408753] RSP: e02b:ffffc9004002f960 EFLAGS: 00010092
[ 2.408774] RAX: 0000000000000000 RBX: 0000000000000031 RCX: 0000000000000000
[ 2.408799] RDX: ffffffffffffffff RSI: ffffc9004002f918 RDI: ffff888039c00900
[ 2.408824] RBP: ffffffff814f9d64 R08: ffff888039c00ab0 R09: ffff888039c00900
[ 2.408849] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888039853818
[ 2.408873] R13: 0000000000000001 R14: ffff888039888640 R15: ffff888039853818
[ 2.408914] FS: 0000000000000000(0000) GS:ffff88803e600000(0000) knlGS:0000000000000000
[ 2.408942] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2.408964] CR2: 0000000000000000 CR3: 000000000220c000 CR4: 0000000000000660
[ 2.408997] Kernel panic - not syncing: Fatal exception
(XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
[-- Attachment #3: 5.txt --]
[-- Type: text/plain, Size: 26620 bytes --]
Xen 4.14.0
(XEN) Xen version 4.14.0 (@) (gcc (Alpine 6.4.0) 6.4.0) debug=n Sat Jul 25 23:45:43 UTC 2020
(XEN) Latest ChangeSet:
(XEN) Bootloader: GRUB 2.03
(XEN) Command line: com1=115200,8n1 console=com1 efi=no-rs dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin
(XEN) Xen image load base address: 0x71000000
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) Disc information:
(XEN) Found 0 MBR signatures
(XEN) Found 1 EDD information structures
(XEN) EFI RAM map:
(XEN) [0000000000000000, 000000000003efff] (usable)
(XEN) [000000000003f000, 000000000003ffff] (ACPI NVS)
(XEN) [0000000000040000, 000000000009ffff] (usable)
(XEN) [0000000000100000, 000000001fffffff] (usable)
(XEN) [0000000020000000, 00000000200fffff] (reserved)
(XEN) [0000000020100000, 0000000076ccafff] (usable)
(XEN) [0000000076ccb000, 0000000076d42fff] (reserved)
(XEN) [0000000076d43000, 0000000076d53fff] (ACPI data)
(XEN) [0000000076d54000, 00000000772ddfff] (ACPI NVS)
(XEN) [00000000772de000, 00000000775f4fff] (reserved)
(XEN) [00000000775f5000, 00000000775f5fff] (usable)
(XEN) [00000000775f6000, 0000000077637fff] (reserved)
(XEN) [0000000077638000, 00000000789e4fff] (usable)
(XEN) [00000000789e5000, 0000000078ff9fff] (reserved)
(XEN) [0000000078ffa000, 0000000078ffffff] (usable)
(XEN) [00000000e0000000, 00000000efffffff] (reserved)
(XEN) [00000000fec00000, 00000000fec00fff] (reserved)
(XEN) [00000000fed01000, 00000000fed01fff] (reserved)
(XEN) [00000000fed03000, 00000000fed03fff] (reserved)
(XEN) [00000000fed08000, 00000000fed08fff] (reserved)
(XEN) [00000000fed0c000, 00000000fed0ffff] (reserved)
(XEN) [00000000fed1c000, 00000000fed1cfff] (reserved)
(XEN) [00000000fee00000, 00000000fee00fff] (reserved)
(XEN) [00000000fef00000, 00000000feffffff] (reserved)
(XEN) [00000000ff900000, 00000000ffffffff] (reserved)
(XEN) System RAM: 1919MB (1965176kB)
(XEN) ACPI: RSDP 76D46000, 0024 (r2 DELL)
(XEN) ACPI: XSDT 76D46088, 0094 (r1 DELL AS09 1072009 AMI 10013)
(XEN) ACPI: FACP 76D52560, 010C (r5 DELL AS09 1072009 AMI 10013)
(XEN) ACPI: DSDT 76D461B0, C3AF (r2 DELL AS09 1072009 INTL 20120913)
(XEN) ACPI: FACS 772DDE80, 0040
(XEN) ACPI: APIC 76D52670, 0068 (r3 DELL AS09 1072009 AMI 10013)
(XEN) ACPI: FPDT 76D526D8, 0044 (r1 DELL AS09 1072009 AMI 10013)
(XEN) ACPI: FIDT 76D52720, 009C (r1 DELL AS09 1072009 AMI 10013)
(XEN) ACPI: MCFG 76D527C0, 003C (r1 DELL AS09 1072009 MSFT 97)
(XEN) ACPI: LPIT 76D52800, 0104 (r1 DELL AS09 3 VLV2 100000D)
(XEN) ACPI: HPET 76D52908, 0038 (r1 DELL AS09 1072009 AMI. 5)
(XEN) ACPI: SSDT 76D52940, 0763 (r1 DELL AS09 3000 INTL 20061109)
(XEN) ACPI: SSDT 76D530A8, 0290 (r1 DELL AS09 3000 INTL 20061109)
(XEN) ACPI: SSDT 76D53338, 017A (r1 DELL AS09 3000 INTL 20061109)
(XEN) ACPI: UEFI 76D534B8, 0042 (r1 DELL AS09 0 0)
(XEN) ACPI: CSRT 76D53500, 014C (r0 DELL AS09 5 INTL 20120624)
(XEN) ACPI: TPM2 76D53650, 0034 (r3 Tpm2Tabl 1 AMI 0)
(XEN) ACPI: SSDT 76D53688, 00C9 (r1 MSFT RHPROXY 1 INTL 20120913)
(XEN) Domain heap initialised
(XEN) ACPI: 32/64X FACS address mismatch in FADT - 772dde80/0000000000000000, using 32
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-86
(XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
(XEN) CPU0: 400..1000 MHz
(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) Support for HVM VMs: RSB
(XEN) Support for PV VMs: RSB
(XEN) XPTI (64-bit PV only): Dom0 enabled, DomU enabled (without PCID)
(XEN) PV L1TF shadowing: Dom0 disabled, DomU disabled
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN) Disabling HPET for being unreliable
(XEN) Platform timer is 3.580MHz ACPI PM Timer
(XEN) Detected 1333.349 MHz processor.
(XEN) I/O virtualisation disabled
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using new ACK method
(XEN) Allocated console ring of 16 KiB.
(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) - VM Functions
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB
(XEN) Brought up 2 CPUs
(XEN) Scheduling granularity: cpu, 1 CPU per sched-resource
(XEN) Dom0 has maximum 295 PIRQs
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2c2c000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 000000006c000000->0000000070000000 (240976 pages to be allocated)
(XEN) Init. ramdisk: 0000000075950000->0000000076bffc5c
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff81000000->ffffffff82c2c000
(XEN) Init. ramdisk: 0000000000000000->0000000000000000
(XEN) Phys-Mach map: 0000008000000000->0000008000200000
(XEN) Start info: ffffffff82c2c000->ffffffff82c2c4b8
(XEN) Xenstore ring: 0000000000000000->0000000000000000
(XEN) Console ring: 0000000000000000->0000000000000000
(XEN) Page tables: ffffffff82c2d000->ffffffff82c48000
(XEN) Boot stack: ffffffff82c48000->ffffffff82c49000
(XEN) TOTAL: ffffffff80000000->ffffffff83000000
(XEN) ENTRY ADDRESS: ffffffff82945180
(XEN) Dom0 has maximum 1 VCPUs
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Scrubbing Free RAM in background
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input)
(XEN) Freed 560kB init memory
mapping kernel into physical memory
about to get started...
[ 0.000000][ T0] Could not determine UEFI Secure Boot status.
[ 0.000000][ T0] Linux version 5.4.51-linuxkit (root@73c74feab71d) (gcc version 8.3.0 (Alpine 8.3.0)) #1 SMP Sat Aug 15 19:42:47 UTC 2020
[ 0.000000][ T0] Command line: console=hvc0 root=(hd0,gpt1)/rootfs.img dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin eve_mem=650M,max:650M eve_max_vcpus=1 ctrd_mem=300M,max:300M ctrd_max_vcpus=1 rootdelay=3 setup_loops eve_installer
[ 0.000000][ T0] x86/fpu: x87 FPU will use FXSAVE
[ 0.000000][ T0] Released 0 page(s)
[ 0.000000][ T0] BIOS-provided physical RAM map:
[ 0.000000][ T0] Xen: [mem 0x0000000000000000-0x000000000003efff] usable
[ 0.000000][ T0] Xen: [mem 0x000000000003f000-0x000000000003ffff] ACPI NVS
[ 0.000000][ T0] Xen: [mem 0x0000000000040000-0x000000000009ffff] usable
[ 0.000000][ T0] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[ 0.000000][ T0] Xen: [mem 0x0000000000100000-0x000000001fffffff] usable
[ 0.000000][ T0] Xen: [mem 0x0000000020000000-0x00000000200fffff] reserved
[ 0.000000][ T0] Xen: [mem 0x0000000020100000-0x0000000040160fff] usable
[ 0.000000][ T0] Xen: [mem 0x0000000076ccb000-0x0000000076d42fff] reserved
[ 0.000000][ T0] Xen: [mem 0x0000000076d43000-0x0000000076d53fff] ACPI data
[ 0.000000][ T0] Xen: [mem 0x0000000076d54000-0x00000000772ddfff] ACPI NVS
[ 0.000000][ T0] Xen: [mem 0x00000000772de000-0x00000000775f4fff] reserved
[ 0.000000][ T0] Xen: [mem 0x00000000775f6000-0x0000000077637fff] reserved
[ 0.000000][ T0] Xen: [mem 0x00000000789e5000-0x0000000078ff9fff] reserved
[ 0.000000][ T0] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[ 0.000000][ T0] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[ 0.000000][ T0] Xen: [mem 0x00000000fed01000-0x00000000fed01fff] reserved
[ 0.000000][ T0] Xen: [mem 0x00000000fed03000-0x00000000fed03fff] reserved
[ 0.000000][ T0] Xen: [mem 0x00000000fed08000-0x00000000fed08fff] reserved
[ 0.000000][ T0] Xen: [mem 0x00000000fed0c000-0x00000000fed0ffff] reserved
[ 0.000000][ T0] Xen: [mem 0x00000000fed1c000-0x00000000fed1cfff] reserved
[ 0.000000][ T0] Xen: [mem 0x00000000fee00000-0x00000000feffffff] reserved
[ 0.000000][ T0] Xen: [mem 0x00000000ff900000-0x00000000ffffffff] reserved
[ 0.000000][ T0] NX (Execute Disable) protection: active
[ 0.000000][ T0] efi: EFI v2.40 by UNKNOWN
[ 0.000000][ T0] efi: ACPI=0x76d46000 ACPI 2.0=0x76d46000 SMBIOS=0xf05b0 ESRT=0x7748b598 MPS=0xfd640
[ 0.000000][ T0] SMBIOS 3.0 present.
[ 0.000000][ T0] DMI: Dell Inc. Edge Gateway 3001/0DY2CV, BIOS 01.00.01 05/16/2017
[ 0.000000][ T0] Hypervisor detected: Xen PV
[ 0.000496][ T0] tsc: Detected 1333.349 MHz processor
[ 0.001202][ T0] last_pfn = 0x40161 max_arch_pfn = 0x400000000
[ 0.001209][ T0] Disabled
[ 0.001214][ T0] x86/PAT: MTRRs disabled, skipping PAT initialization too.
[ 0.001228][ T0] x86/PAT: Configuration [0-7]: WB WT UC- UC WC WP UC UC
[ 0.001323][ T0] Kernel/User page tables isolation: disabled on XEN PV.
[ 0.657385][ T0] Secure boot could not be determined
[ 0.657398][ T0] RAMDISK: [mem 0x04000000-0x052affff]
[ 0.660824][ T0] ACPI: Early table checksum verification disabled
[ 0.660860][ T0] ACPI: RSDP 0x0000000076D46000 000024 (v02 DELL )
[ 0.660891][ T0] ACPI: XSDT 0x0000000076D46088 000094 (v01 DELL AS09 01072009 AMI 00010013)
[ 0.660951][ T0] ACPI: FACP 0x0000000076D52560 00010C (v05 DELL AS09 01072009 AMI 00010013)
[ 0.661023][ T0] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 128/32 (20190816/tbfadt-569)
[ 0.661062][ T0] ACPI: DSDT 0x0000000076D461B0 00C3AF (v02 DELL AS09 01072009 INTL 20120913)
[ 0.661100][ T0] ACPI: FACS 0x00000000772DDE80 000040
[ 0.661136][ T0] ACPI: APIC 0x0000000076D52670 000068 (v03 DELL AS09 01072009 AMI 00010013)
[ 0.661174][ T0] ACPI: FPDT 0x0000000076D526D8 000044 (v01 DELL AS09 01072009 AMI 00010013)
[ 0.661212][ T0] ACPI: FIDT 0x0000000076D52720 00009C (v01 DELL AS09 01072009 AMI 00010013)
[ 0.661249][ T0] ACPI: MCFG 0x0000000076D527C0 00003C (v01 DELL AS09 01072009 MSFT 00000097)
[ 0.661287][ T0] ACPI: LPIT 0x0000000076D52800 000104 (v01 DELL AS09 00000003 VLV2 0100000D)
[ 0.661324][ T0] ACPI: HPET 0x0000000076D52908 000038 (v01 DELL AS09 01072009 AMI. 00000005)
[ 0.661362][ T0] ACPI: SSDT 0x0000000076D52940 000763 (v01 DELL AS09 00003000 INTL 20061109)
[ 0.661399][ T0] ACPI: SSDT 0x0000000076D530A8 000290 (v01 DELL AS09 00003000 INTL 20061109)
[ 0.661437][ T0] ACPI: SSDT 0x0000000076D53338 00017A (v01 DELL AS09 00003000 INTL 20061109)
[ 0.661475][ T0] ACPI: UEFI 0x0000000076D534B8 000042 (v01 DELL AS09 00000000 00000000)
[ 0.661513][ T0] ACPI: CSRT 0x0000000076D53500 00014C (v00 DELL AS09 00000005 INTL 20120624)
[ 0.661550][ T0] ACPI: TPM2 0x0000000076D53650 000034 (v03 Tpm2Tabl 00000001 AMI 00000000)
[ 0.661588][ T0] ACPI: SSDT 0x0000000076D53688 0000C9 (v01 MSFT RHPROXY 00000001 INTL 20120913)
[ 0.661682][ T0] Setting APIC routing to Xen PV.
[ 0.677017][ T0] Zone ranges:
[ 0.677027][ T0] DMA [mem 0x0000000000001000-0x0000000000ffffff]
[ 0.677035][ T0] DMA32 [mem 0x0000000001000000-0x0000000040160fff]
[ 0.677042][ T0] Normal empty
[ 0.677048][ T0] Movable zone start for each node
[ 0.677052][ T0] Early memory node ranges
[ 0.677058][ T0] node 0: [mem 0x0000000000001000-0x000000000003efff]
[ 0.677066][ T0] node 0: [mem 0x0000000000040000-0x000000000009ffff]
[ 0.677072][ T0] node 0: [mem 0x0000000000100000-0x000000001fffffff]
[ 0.677079][ T0] node 0: [mem 0x0000000020100000-0x0000000040160fff]
[ 0.678071][ T0] Zeroed struct page in unavailable ranges: 32769 pages
[ 0.678076][ T0] Initmem setup node 0 [mem 0x0000000000001000-0x0000000040160fff]
[ 0.687279][ T0] p2m virtual area at (____ptrval____), size is 40000000
[ 1.302973][ T0] Remapped 353 page(s)
[ 1.303022][ T0] x86/hpet: Will disable the HPET for this platform because it's not reliable
[ 1.304326][ T0] ACPI: PM-Timer IO Port: 0x408
[ 1.304418][ T0] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[ 1.304427][ T0] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[ 1.304481][ T0] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-86
[ 1.304507][ T0] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 1.304517][ T0] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 1.304560][ T0] Using ACPI (MADT) for SMP configuration information
[ 1.304577][ T0] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[ 1.304602][ T0] smpboot: Allowing 2 CPUs, 0 hotplug CPUs
[ 1.304677][ T0] [mem 0x78ffa000-0xdfffffff] available for PCI devices
[ 1.304690][ T0] Booting paravirtualized kernel on Xen
[ 1.304697][ T0] Xen version: 4.14.0 (preserve-AD)
[ 1.304706][ T0] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 1.723807][ T0] setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:2 nr_node_ids:1
[ 1.724780][ T0] percpu: Embedded 52 pages/cpu s174616 r8192 d30184 u1048576
[ 1.724965][ T0] Built 1 zonelists, mobility grouping on. Total pages: 258020
[ 1.724975][ T0] Kernel command line: console=hvc0 root=(hd0,gpt1)/rootfs.img dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin eve_mem=650M,max:650M eve_max_vcpus=1 ctrd_mem=300M,max:300M ctrd_max_vcpus=1 rootdelay=3 setup_loops eve_installer
[ 1.726097][ T0] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[ 1.726307][ T0] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
[ 1.726824][ T0] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 1.817745][ T0] software IO TLB: mapped [mem 0x3a800000-0x3e800000] (64MB)
[ 1.830013][ T0] Memory: 910092K/1048572K available (14341K kernel code, 1755K rwdata, 3652K rodata, 1760K init, 1188K bss, 138480K reserved, 0K cma-reserved)
[ 1.830061][ T0] random: get_random_u32 called from ____cache_alloc+0x5f0/0x7ae with crng_init=0
[ 1.830460][ T0] ftrace: allocating 50194 entries in 197 pages
[ 1.880657][ T0] rcu: Hierarchical RCU implementation.
[ 1.880668][ T0] rcu: RCU restricting CPUs from NR_CPUS=128 to nr_cpu_ids=1.
[ 1.880674][ T0] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 1.880679][ T0] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[ 1.895646][ T0] Using NULL legacy PIC
[ 1.895659][ T0] NR_IRQS: 8448, nr_irqs: 256, preallocated irqs: 0
[ 1.895819][ T0] xen:events: Using FIFO-based ABI
[ 1.897617][ T0] Console: colour dummy device 80x25
[ 1.898524][ T0] printk: console [tty0] enabled
[ 1.900359][ T0] printk: console [hvc0] enabled
[ 1.900397][ T0] ACPI: Core revision 20190816
[ 1.905122][ T0] clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 1.905180][ T0] installing Xen timer for CPU 0
[ 1.905272][ T0] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x13382d91c0b, max_idle_ns: 440795204963 ns
[ 1.905317][ T0] Calibrating delay loop (skipped), value calculated using timer frequency.. 2666.69 BogoMIPS (lpj=13333490)
[ 1.905359][ T0] pid_max: default: 32768 minimum: 301
[ 1.905564][ T0] LSM: Security Framework initializing
[ 1.905598][ T0] Yama: becoming mindful.
[ 1.905714][ T0] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
[ 1.905755][ T0] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
[ 1.906957][ T0] Last level iTLB entries: 4KB 48, 2MB 0, 4MB 0
[ 1.906994][ T0] Last level dTLB entries: 4KB 128, 2MB 16, 4MB 16, 1GB 0
[ 1.907028][ T0] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
[ 1.907064][ T0] Spectre V2 : Mitigation: Full generic retpoline
[ 1.907087][ T0] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
[ 1.907122][ T0] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[ 1.978250][ T0] Freeing SMP alternatives memory: 20K
[ 1.979534][ T1] VPMU disabled by hypervisor.
[ 1.980471][ T1] Performance Events: unsupported p6 CPU model 55 no PMU driver, software events only.
[ 1.980810][ T1] rcu: Hierarchical SRCU implementation.
[ 1.981256][ T1] NMI watchdog: Perf NMI watchdog permanently disabled
[ 1.981609][ T1] smp: Bringing up secondary CPUs ...
[ 1.981657][ T1] smp: Brought up 1 node, 1 CPU
[ 1.981680][ T1] smpboot: Max logical packages: 2
[ 1.982278][ T1] devtmpfs: initialized
[ 1.982485][ T1] x86/mm: Memory block size: 128MB
[ 1.984721][ T1] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 1.984778][ T1] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[ 1.985040][ T1] pinctrl core: initialized pinctrl subsystem
[ 1.985609][ T1] NET: Registered protocol family 16
[ 1.985684][ T1] xen:grant_table: Grant tables using version 1 layout
[ 1.985754][ T1] Grant table initialized
[ 1.986657][ T1] audit: initializing netlink subsys (disabled)
[ 1.987230][ T16] audit: type=2000 audit(1325376223.204:1): state=initialized audit_enabled=0 res=1
[ 1.988180][ T1] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[ 1.988220][ T1] ACPI: bus type PCI registered
[ 1.988732][ T1] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[ 1.988777][ T1] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[ 2.198551][ T1] PCI: Using configuration type 1 for base access
[ 2.215104][ T1] cryptd: max_cpu_qlen set to 1000
[ 2.223670][ T1] ACPI: Added _OSI(Module Device)
[ 2.223706][ T1] ACPI: Added _OSI(Processor Device)
[ 2.223729][ T1] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 2.223750][ T1] ACPI: Added _OSI(Processor Aggregator Device)
[ 2.223775][ T1] ACPI: Added _OSI(Linux-Dell-Video)
[ 2.223798][ T1] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[ 2.223823][ T1] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[ 2.256656][ T1] ACPI: 5 ACPI AML tables successfully acquired and loaded
[ 2.263684][ T1] ACPI: Dynamic OEM Table Load:
[ 2.263732][ T1] ACPI: SSDT 0xFFFF88803A77F000 0002B4 (v01 PmRef Cpu0Ist 00003000 INTL 20061109)
[ 2.266247][ T1] ACPI: Dynamic OEM Table Load:
[ 2.266292][ T1] ACPI: SSDT 0xFFFF88803A7A9000 000433 (v01 PmRef Cpu0Cst 00003001 INTL 20061109)
[ 2.271615][ T1] ACPI: Interpreter enabled
[ 2.271669][ T1] ACPI: (supports S0 S5)
[ 2.271692][ T1] ACPI: Using IOAPIC for interrupt routing
[ 2.271838][ T1] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 2.273637][ T1] ACPI: Enabled 6 GPEs in block 00 to 3F
[ 2.274194][ T12] ACPI Error: No handler for Region [TH00] (000000007cec6abe) [GenericSerialBus] (20190816/evregion-132)
[ 2.274241][ T12] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20190816/exfldio-265)
[ 2.274281][ T12] ACPI Error: Aborting method \_GPE._L02 due to previous error (AE_NOT_EXIST) (20190816/psparse-531)
[ 2.274339][ T12] ACPI Error: AE_NOT_EXIST, while evaluating GPE method [_L02] (20190816/evgpe-515)
[ 2.295211][ T1] ACPI: Power Resource [USBC] (on)
[ 2.299371][ T1] ACPI: Power Resource [PLPE] (on)
[ 2.300364][ T1] ACPI: Power Resource [PLPE] (on)
[ 2.316781][ T1] ACPI: Power Resource [CLK0] (on)
[ 2.316981][ T1] ACPI: Power Resource [CLK1] (on)
[ 2.323061][ T1] ACPI: Power Resource [FN00] (off)
[ 2.325233][ T1] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 2.325282][ T1] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[ 2.325961][ T1] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME]
[ 2.326608][ T1] acpi PNP0A08:00: _OSC: OS now controls [PCIeCapability LTR]
[ 2.326641][ T1] acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS configuration
[ 2.327421][ T1] PCI host bridge to bus 0000:00
[ 2.327454][ T1] pci_bus 0000:00: root bus resource [io 0x0070-0x0077]
[ 2.327483][ T1] pci_bus 0000:00: root bus resource [io 0x0000-0x006f window]
[ 2.327514][ T1] pci_bus 0000:00: root bus resource [io 0x0078-0x0cf7 window]
[ 2.327544][ T1] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
[ 2.327575][ T1] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[ 2.327605][ T1] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff window]
[ 2.327636][ T1] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000fffff window]
[ 2.327667][ T1] pci_bus 0000:00: root bus resource [mem 0x80000000-0x80336ffe window]
[ 2.327699][ T1] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 2.327786][ T1] pci 0000:00:00.0: [8086:0f00] type 00 class 0x060000
[ 2.328920][ T1] pci 0000:00:14.0: [8086:0f35] type 00 class 0x0c0330
[ 2.329114][ T1] pci 0000:00:14.0: reg 0x10: [mem 0x80300000-0x8030ffff 64bit]
[ 2.329651][ T1] pci 0000:00:14.0: PME# supported from D3hot D3cold
[ 2.330406][ T1] pci 0000:00:1a.0: [8086:0f18] type 00 class 0x108000
[ 2.330582][ T1] pci 0000:00:1a.0: reg 0x10: [mem 0x80100000-0x801fffff]
[ 2.330690][ T1] pci 0000:00:1a.0: reg 0x14: [mem 0x80000000-0x800fffff]
[ 2.331265][ T1] pci 0000:00:1a.0: PME# supported from D0 D3hot
[ 2.332096][ T1] pci 0000:00:1c.0: [8086:0f48] type 01 class 0x060400
[ 2.332794][ T1] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[ 2.333549][ T1] pci 0000:00:1c.1: [8086:0f4a] type 01 class 0x060400
[ 2.334240][ T1] pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold
[ 2.334979][ T1] pci 0000:00:1c.2: [8086:0f4c] type 01 class 0x060400
[ 2.335688][ T1] pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold
[ 2.336464][ T1] pci 0000:00:1c.3: [8086:0f4e] type 01 class 0x060400
[ 2.337154][ T1] pci 0000:00:1c.3: PME# supported from D0 D3hot D3cold
[ 2.337932][ T1] pci 0000:00:1f.0: [8086:0f1c] type 00 class 0x060100
[ 2.339184][ T1] pci 0000:00:1f.3: [8086:0f12] type 00 class 0x0c0500
[ 2.339369][ T1] pci 0000:00:1f.3: reg 0x10: [mem 0x80318000-0x8031801f]
[ 2.339649][ T1] pci 0000:00:1f.3: reg 0x20: [io 0xe000-0xe01f]
[ 2.340943][ T1] pci 0000:00:1c.0: PCI bridge to [bus 01]
[ 2.341404][ T1] pci 0000:02:00.0: [10ec:8136] type 00 class 0x020000
[ 2.341627][ T1] pci 0000:02:00.0: reg 0x10: [io 0xd000-0xd0ff]
[ 2.341889][ T1] pci 0000:02:00.0: reg 0x18: [mem 0x80204000-0x80204fff 64bit]
[ 2.342057][ T1] pci 0000:02:00.0: reg 0x20: [mem 0x80200000-0x80203fff 64bit pref]
[ 2.342782][ T1] pci 0000:02:00.0: supports D1 D2
[ 2.342807][ T1] pci 0000:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 2.343678][ T1] pci 0000:00:1c.1: PCI bridge to [bus 02]
[ 2.343727][ T1] pci 0000:00:1c.1: bridge window [io 0xd000-0xdfff]
[ 2.343773][ T1] pci 0000:00:1c.1: bridge window [mem 0x80200000-0x802fffff]
[ 2.344097][ T1] pci 0000:00:1c.2: PCI bridge to [bus 03]
[ 2.344438][ T1] pci 0000:00:1c.3: PCI bridge to [bus 04]
[ 2.346496][ T1] ACPI: PCI Interrupt Link [LNKA] (IRQs *3 4 5 6 12 14 15)
[ 2.346785][ T1] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 12 14 15)
[ 2.347067][ T1] ACPI: PCI Interrupt Link [LNKC] (IRQs *3 4 5 6 12 14 15)
[ 2.347346][ T1] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 12 14 15)
[ 2.347625][ T1] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 6 12 14 15)
[ 2.347906][ T1] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 *5 6 12 14 15)
[ 2.348201][ T1] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 12 14 15) *0, disabled.
[ 2.348485][ T1] ACPI: PCI Interrupt Link [LNKH] (IRQs *3 4 5 6 12 14 15)
[ 2.350451][ T1] ------------[ cut here ]------------
[ 2.350483][ T1] kernel BUG at drivers/xen/events/events_base.c:514!
[ 2.350517][ T1] invalid opcode: 0000 [#1] SMP NOPTI
[ 2.350541][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.51-linuxkit #1
[ 2.350589][ T1] Hardware name: Dell Inc. Edge Gateway 3001/0DY2CV, BIOS 01.00.01 05/16/2017
[ 2.350629][ T1] RIP: e030:__startup_pirq+0x38/0x119
[ 2.350653][ T1] Code: 83 ec 18 65 48 8b 04 25 28 00 00 00 48 89 44 24 10 31 c0 e8 e0 f5 ff ff 89 df 49 89 c4 e8 9c fc ff ff 41 83 7c 24 14 01 74 02 <0f> 0b 41 89 c5 85 c0 0f 85 82 00 00 00 89 df e8 0a f8 ff ff bf 02
[ 2.350707][ T1] RSP: e02b:ffffc900400379d0 EFLAGS: 00010092
[ 2.350731][ T1] RAX: 0000000000000000 RBX: 0000000000000031 RCX: 00000000000001b0
[ 2.350759][ T1] RDX: ffff888039cb0c00 RSI: 0000000000000000 RDI: ffffffff8245eae0
[ 2.350786][ T1] RBP: ffffffff81579f82 R08: 0000000000000000 R09: ffff88803a000f30
[ 2.350813][ T1] R10: 0000000000000000 R11: ffffffff8245eae0 R12: ffff888039cfc818
[ 2.350840][ T1] R13: 0000000000000001 R14: ffff88803a7173c0 R15: ffff888039cfc818
[ 2.350894][ T1] FS: 0000000000000000(0000) GS:ffff88803e800000(0000) knlGS:0000000000000000
[ 2.350926][ T1] CS: 10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2.350950][ T1] CR2: 0000000000000000 CR3: 000000000240c000 CR4: 0000000000000660
[ 2.350985][ T1] Call Trace:
[ 2.351015][ T1] ? __raw_callee_save___native_queued_spin_unlock+0x11/0x1e
[ 2.351068][ T1] ? byt_gpio_runtime_resume+0x8/0x8
[ 2.351094][ T1] __irq_startup+0x2d/0x59
[ 2.351118][ T1] irq_startup+0x41/0xce
[ 2.351141][ T1] ? byt_gpio_runtime_resume+0x8/0x8
[ 2.351165][ T1] irq_set_chained_handler_and_data+0x50/0x7f
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.4ce
Status Code Available
DXE Status Code Available
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Xen 4.14.0 is busted on Dell 300x IoT Gateways
2020-08-18 22:09 Xen 4.14.0 is busted on Dell 300x IoT Gateways Roman Shaposhnik
@ 2020-08-18 22:20 ` Andrew Cooper
2020-08-18 22:34 ` Roman Shaposhnik
2020-08-21 1:39 ` Stefano Stabellini
2020-08-21 7:15 ` [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data Sergey Temerkhanov
2 siblings, 1 reply; 19+ messages in thread
From: Andrew Cooper @ 2020-08-18 22:20 UTC (permalink / raw)
To: Roman Shaposhnik, Xen-devel
Cc: Roger Pau Monné,
Paul Durrant, Jan Beulich, Juergen Gross, Boris Ostrovsky
On 18/08/2020 23:09, Roman Shaposhnik wrote:
> Hi!
>
> first things first -- booting on those devices have always
> required efi=no-rs
That is a bug. Please start a separate thread about it. EFI Runtime
Services are de-facto mandatory on modern systems, and it is totally
unacceptable (from a users perspective) that Xen just doesn't work by
default.
It needs fixing.
> -- but it seems that Xen 4.14 is now
> busted at a more fundamental level. I'm attaching two
> boot sequences (one with kernel 4.19.5 and one with 5.4.51)
> in the hopes that this may provide some clues right away.
As a note, from your logs:
Kernel command line: console=hvc0 root=(hd0,gpt1)/rootfs.img
dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin
eve_mem=650M,max:650M eve_max_vcpus=1 ctrd_mem=300M,max:300M
ctrd_max_vcpus=1 rootdelay=3 setup_loops eve_installer
You've got some Xen command line parameters on the Kernel command line,
which won't be helping matters.
>
> Any help would be greatly appreciated!
>
> Oh, and finally it appears that this is NOT a regression from
> Xen 4.13 -- it fails the same way. I haven't tried Xen's earlier
> than that.
This is a Linux issue, not a Xen issue.
It is hitting a BUG_ON() while setting up interrupts.
Interestingly, they are both in byt_gpio_runtime_resume() which I guess
is BayTrail as the Intel platform, which probably means that something
pertaining to GPIO interrupts isn't being initialised normally.
~Andrew
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Xen 4.14.0 is busted on Dell 300x IoT Gateways
2020-08-18 22:20 ` Andrew Cooper
@ 2020-08-18 22:34 ` Roman Shaposhnik
0 siblings, 0 replies; 19+ messages in thread
From: Roman Shaposhnik @ 2020-08-18 22:34 UTC (permalink / raw)
To: Andrew Cooper
Cc: Xen-devel, Roger Pau Monné,
Paul Durrant, Jan Beulich, Juergen Gross, Boris Ostrovsky
[-- Attachment #1: Type: text/plain, Size: 2851 bytes --]
Hi Andrew!
thanks for replying so quickly -- much appreciated.
On Tue, Aug 18, 2020 at 3:20 PM Andrew Cooper <andrew.cooper3@citrix.com>
wrote:
> On 18/08/2020 23:09, Roman Shaposhnik wrote:
> > Hi!
> >
> > first things first -- booting on those devices have always
> > required efi=no-rs
>
> That is a bug. Please start a separate thread about it. EFI Runtime
> Services are de-facto mandatory on modern systems, and it is totally
> unacceptable (from a users perspective) that Xen just doesn't work by
> default.
>
> It needs fixing.
>
Sure, but right now it is tough to start that thread on account of not
having
anything functional on these devices -- I can remove byt_gpio support from
the linux kernel -- but that doesn't seem right to me.
IOW, I don't really have a functional Dom0. If someone can help with that
-- I can
then start the thread.
Also, just as an observation, I wouldn't surprised if UEFI implementation
on these devices pushes the envelope on what it means to be standard
compliant UEFI so to speak -- but you're 100% right -- if we can make
Xen run on them without tweaks -- that'd be awesome.
> > -- but it seems that Xen 4.14 is now
> > busted at a more fundamental level. I'm attaching two
> > boot sequences (one with kernel 4.19.5 and one with 5.4.51)
> > in the hopes that this may provide some clues right away.
>
> As a note, from your logs:
>
> Kernel command line: console=hvc0 root=(hd0,gpt1)/rootfs.img
> dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin
> eve_mem=650M,max:650M eve_max_vcpus=1 ctrd_mem=300M,max:300M
> ctrd_max_vcpus=1 rootdelay=3 setup_loops eve_installer
>
You've got some Xen command line parameters on the Kernel command line,
> which won't be helping matters.
>
That's actually on purpose -- Project EVE uses Xen syntax for setting
up these values for cases where we are not running under Xen and need
to tickle other hypervisors (like KVM or ACRN) just so from the Dom0 itself.
See below on running without Xen.
> >
> > Any help would be greatly appreciated!
> >
> > Oh, and finally it appears that this is NOT a regression from
> > Xen 4.13 -- it fails the same way. I haven't tried Xen's earlier
> > than that.
>
> This is a Linux issue, not a Xen issue.
>
It seems like a combination of both frankly -- note that very same kernels
have no trouble booting without Xen and work perfectly with KVM.
> It is hitting a BUG_ON() while setting up interrupts.
>
> Interestingly, they are both in byt_gpio_runtime_resume() which I guess
> is BayTrail as the Intel platform, which probably means that something
> pertaining to GPIO interrupts isn't being initialised normally.
>
Or Xen isn't passing some vital info to the Linux kernel. Or setting up some
weird memory mapping, etc. Like I said -- there's no issue with running
these kernels by themselves.
Thanks,
Roman.
[-- Attachment #2: Type: text/html, Size: 4633 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Xen 4.14.0 is busted on Dell 300x IoT Gateways
2020-08-18 22:09 Xen 4.14.0 is busted on Dell 300x IoT Gateways Roman Shaposhnik
2020-08-18 22:20 ` Andrew Cooper
@ 2020-08-21 1:39 ` Stefano Stabellini
2020-08-21 7:15 ` [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data Sergey Temerkhanov
2 siblings, 0 replies; 19+ messages in thread
From: Stefano Stabellini @ 2020-08-21 1:39 UTC (permalink / raw)
To: Roman Shaposhnik
Cc: Xen-devel, Roger Pau Monné,
Andrew Cooper, Paul Durrant, Jan Beulich, sstabellini
[-- Attachment #1: Type: text/plain, Size: 2230 bytes --]
On Tue, 18 Aug 2020, Roman Shaposhnik wrote:
> Hi!
> first things first -- booting on those devices have always
> required efi=no-rs -- but it seems that Xen 4.14 is now
> busted at a more fundamental level. I'm attaching two
> boot sequences (one with kernel 4.19.5 and one with 5.4.51)
> in the hopes that this may provide some clues right away.
>
> Any help would be greatly appreciated!
>
> Oh, and finally it appears that this is NOT a regression from
> Xen 4.13 -- it fails the same way. I haven't tried Xen's earlier
> than that.
FYI Roman and I tracked down the issue and it is due to the gpio
controller driver (drivers/pinctrl/intel/pinctrl-baytrail.c) overwriting
the interrupt handler data used by Xen to store the irq_data structure.
I have a very small tentative workaround, see below. It allows the
kernel to boot successfully as dom0 and gpio writes work. I am still
thinking on how to fix the issue properly in an upstreamable way, but I
wanted to send this out to the list right away in case somebody else is
stuck on this problem.
diff --git a/drivers/pinctrl/intel/pinctrl-baytrail.c b/drivers/pinctrl/intel/pinctrl-baytrail.c
index f38d596efa05..acd28a9e6a8a 100644
--- a/drivers/pinctrl/intel/pinctrl-baytrail.c
+++ b/drivers/pinctrl/intel/pinctrl-baytrail.c
@@ -1604,8 +1604,8 @@ static struct irq_chip byt_irqchip = {
static void byt_gpio_irq_handler(struct irq_desc *desc)
{
struct irq_data *data = irq_desc_get_irq_data(desc);
- struct byt_gpio *vg = gpiochip_get_data(
- irq_desc_get_handler_data(desc));
+ struct gpio_chip *gc = irq_desc_get_chip_data(desc);
+ struct byt_gpio *vg = (struct byt_gpio *)gc;
struct irq_chip *chip = irq_data_get_irq_chip(data);
u32 base, pin;
void __iomem *reg;
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index a2b3d9de999c..b9551fb41ed1 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -1003,7 +1003,8 @@ irq_set_chained_handler_and_data(unsigned int irq, irq_flow_handler_t handle,
if (!desc)
return;
- desc->irq_common_data.handler_data = data;
+ if (!desc->irq_common_data.handler_data)
+ desc->irq_common_data.handler_data = data;
__irq_do_set_handler(desc, handle, 1, NULL);
irq_put_desc_busunlock(desc, flags);
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data
2020-08-18 22:09 Xen 4.14.0 is busted on Dell 300x IoT Gateways Roman Shaposhnik
2020-08-18 22:20 ` Andrew Cooper
2020-08-21 1:39 ` Stefano Stabellini
@ 2020-08-21 7:15 ` Sergey Temerkhanov
2020-08-21 7:15 ` [PATCH 1/2] Xen: Use a dedicated irq_info structure pointer Sergey Temerkhanov
` (2 more replies)
2 siblings, 3 replies; 19+ messages in thread
From: Sergey Temerkhanov @ 2020-08-21 7:15 UTC (permalink / raw)
To: xen-devel; +Cc: Sergey Temerkhanov
Use a dedicated pointer for IRQ data to avoid conflicts with some
other parts of the kernel code which my use handler_data for their
own purposes while still running on Xen
Sergey Temerkhanov (2):
Xen: Use a dedicated irq_info structure pointer
Xen: Rename irq_info structure
drivers/xen/events/events_2l.c | 2 +-
drivers/xen/events/events_base.c | 80 +++++++++++++---------------
drivers/xen/events/events_fifo.c | 5 +-
drivers/xen/events/events_internal.h | 12 ++---
include/linux/irq.h | 17 ++++++
kernel/irq/chip.c | 14 +++++
6 files changed, 78 insertions(+), 52 deletions(-)
--
2.26.2
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 1/2] Xen: Use a dedicated irq_info structure pointer
2020-08-21 7:15 ` [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data Sergey Temerkhanov
@ 2020-08-21 7:15 ` Sergey Temerkhanov
2020-08-21 7:15 ` [PATCH 2/2] Xen: Rename irq_info structure Sergey Temerkhanov
2020-08-21 10:18 ` [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data Jürgen Groß
2 siblings, 0 replies; 19+ messages in thread
From: Sergey Temerkhanov @ 2020-08-21 7:15 UTC (permalink / raw)
To: xen-devel; +Cc: Sergey Temerkhanov
Use a dedicated irq_info structure pointer to avoid conflicts
with other parts of the kernel code
Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com>
---
drivers/xen/events/events_base.c | 62 +++++++++++++++-----------------
include/linux/irq.h | 15 ++++++++
kernel/irq/chip.c | 14 ++++++++
3 files changed, 57 insertions(+), 34 deletions(-)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 8d49b91d92cd..bcc3af399016 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -151,12 +151,6 @@ int get_evtchn_to_irq(unsigned evtchn)
return evtchn_to_irq[EVTCHN_ROW(evtchn)][EVTCHN_COL(evtchn)];
}
-/* Get info for IRQ */
-struct irq_info *info_for_irq(unsigned irq)
-{
- return irq_get_handler_data(irq);
-}
-
/* Constructors for packed IRQ information. */
static int xen_irq_info_common_setup(struct irq_info *info,
unsigned irq,
@@ -185,7 +179,7 @@ static int xen_irq_info_common_setup(struct irq_info *info,
static int xen_irq_info_evtchn_setup(unsigned irq,
unsigned evtchn)
{
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
return xen_irq_info_common_setup(info, irq, IRQT_EVTCHN, evtchn, 0);
}
@@ -195,7 +189,7 @@ static int xen_irq_info_ipi_setup(unsigned cpu,
unsigned evtchn,
enum ipi_vector ipi)
{
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
info->u.ipi = ipi;
@@ -209,7 +203,7 @@ static int xen_irq_info_virq_setup(unsigned cpu,
unsigned evtchn,
unsigned virq)
{
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
info->u.virq = virq;
@@ -225,7 +219,7 @@ static int xen_irq_info_pirq_setup(unsigned irq,
uint16_t domid,
unsigned char flags)
{
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
info->u.pirq.pirq = pirq;
info->u.pirq.gsi = gsi;
@@ -249,7 +243,7 @@ unsigned int evtchn_from_irq(unsigned irq)
if (unlikely(WARN(irq >= nr_irqs, "Invalid irq %d!\n", irq)))
return 0;
- return info_for_irq(irq)->evtchn;
+ return xen_get_irq_info(irq)->evtchn;
}
unsigned irq_from_evtchn(unsigned int evtchn)
@@ -265,7 +259,7 @@ int irq_from_virq(unsigned int cpu, unsigned int virq)
static enum ipi_vector ipi_from_irq(unsigned irq)
{
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
BUG_ON(info == NULL);
BUG_ON(info->type != IRQT_IPI);
@@ -275,7 +269,7 @@ static enum ipi_vector ipi_from_irq(unsigned irq)
static unsigned virq_from_irq(unsigned irq)
{
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
BUG_ON(info == NULL);
BUG_ON(info->type != IRQT_VIRQ);
@@ -285,7 +279,7 @@ static unsigned virq_from_irq(unsigned irq)
static unsigned pirq_from_irq(unsigned irq)
{
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
BUG_ON(info == NULL);
BUG_ON(info->type != IRQT_PIRQ);
@@ -295,12 +289,12 @@ static unsigned pirq_from_irq(unsigned irq)
static enum xen_irq_type type_from_irq(unsigned irq)
{
- return info_for_irq(irq)->type;
+ return xen_get_irq_info(irq)->type;
}
unsigned cpu_from_irq(unsigned irq)
{
- return info_for_irq(irq)->cpu;
+ return xen_get_irq_info(irq)->cpu;
}
unsigned int cpu_from_evtchn(unsigned int evtchn)
@@ -323,7 +317,7 @@ static bool pirq_check_eoi_map(unsigned irq)
static bool pirq_needs_eoi_flag(unsigned irq)
{
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
BUG_ON(info->type != IRQT_PIRQ);
return info->u.pirq.flags & PIRQ_NEEDS_EOI;
@@ -332,7 +326,7 @@ static bool pirq_needs_eoi_flag(unsigned irq)
static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
{
int irq = get_evtchn_to_irq(chn);
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
BUG_ON(irq == -1);
#ifdef CONFIG_SMP
@@ -375,7 +369,7 @@ static void xen_irq_init(unsigned irq)
info->type = IRQT_UNBOUND;
info->refcnt = -1;
- irq_set_handler_data(irq, info);
+ xen_set_irq_info(irq, info);
list_add_tail(&info->list, &xen_irq_list_head);
}
@@ -424,14 +418,14 @@ static int __must_check xen_allocate_irq_gsi(unsigned gsi)
static void xen_free_irq(unsigned irq)
{
- struct irq_info *info = irq_get_handler_data(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
if (WARN_ON(!info))
return;
list_del(&info->list);
- irq_set_handler_data(irq, NULL);
+ xen_set_irq_info(irq, NULL);
WARN_ON(info->refcnt > 0);
@@ -456,7 +450,7 @@ static void xen_evtchn_close(unsigned int port)
static void pirq_query_unmask(int irq)
{
struct physdev_irq_status_query irq_status;
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
BUG_ON(info->type != IRQT_PIRQ);
@@ -506,7 +500,7 @@ static void mask_ack_pirq(struct irq_data *data)
static unsigned int __startup_pirq(unsigned int irq)
{
struct evtchn_bind_pirq bind_pirq;
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
int evtchn = evtchn_from_irq(irq);
int rc;
@@ -559,7 +553,7 @@ static unsigned int startup_pirq(struct irq_data *data)
static void shutdown_pirq(struct irq_data *data)
{
unsigned int irq = data->irq;
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
unsigned evtchn = evtchn_from_irq(irq);
BUG_ON(info->type != IRQT_PIRQ);
@@ -601,7 +595,7 @@ EXPORT_SYMBOL_GPL(xen_irq_from_gsi);
static void __unbind_from_irq(unsigned int irq)
{
int evtchn = evtchn_from_irq(irq);
- struct irq_info *info = irq_get_handler_data(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
if (info->refcnt > 0) {
info->refcnt--;
@@ -763,7 +757,7 @@ int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct msi_desc *msidesc,
int xen_destroy_irq(int irq)
{
struct physdev_unmap_pirq unmap_irq;
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
int rc = -ENOENT;
mutex_lock(&irq_mapping_update_lock);
@@ -855,7 +849,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
/* New interdomain events are bound to VCPU 0. */
bind_evtchn_to_cpu(evtchn, 0);
} else {
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
}
@@ -898,7 +892,7 @@ static int bind_ipi_to_irq(unsigned int ipi, unsigned int cpu)
}
bind_evtchn_to_cpu(evtchn, cpu);
} else {
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
WARN_ON(info == NULL || info->type != IRQT_IPI);
}
@@ -1001,7 +995,7 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu, bool percpu)
bind_evtchn_to_cpu(evtchn, cpu);
} else {
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
WARN_ON(info == NULL || info->type != IRQT_VIRQ);
}
@@ -1105,7 +1099,7 @@ int bind_ipi_to_irqhandler(enum ipi_vector ipi,
void unbind_from_irqhandler(unsigned int irq, void *dev_id)
{
- struct irq_info *info = irq_get_handler_data(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
if (WARN_ON(!info))
return;
@@ -1139,7 +1133,7 @@ int evtchn_make_refcounted(unsigned int evtchn)
if (irq == -1)
return -ENOENT;
- info = irq_get_handler_data(irq);
+ info = xen_get_irq_info(irq);
if (!info)
return -ENOENT;
@@ -1167,7 +1161,7 @@ int evtchn_get(unsigned int evtchn)
if (irq == -1)
goto done;
- info = irq_get_handler_data(irq);
+ info = xen_get_irq_info(irq);
if (!info)
goto done;
@@ -1263,7 +1257,7 @@ EXPORT_SYMBOL_GPL(xen_hvm_evtchn_do_upcall);
/* Rebind a new event channel to an existing irq. */
void rebind_evtchn_irq(int evtchn, int irq)
{
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
if (WARN_ON(!info))
return;
@@ -1551,7 +1545,7 @@ void xen_poll_irq(int irq)
/* Check whether the IRQ line is shared with other guests. */
int xen_test_irq_shared(int irq)
{
- struct irq_info *info = info_for_irq(irq);
+ struct irq_info *info = xen_get_irq_info(irq);
struct physdev_irq_status_query irq_status;
if (WARN_ON(!info))
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 6ecaf056ab63..e094d31916e2 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -123,6 +123,7 @@ enum {
struct msi_desc;
struct irq_domain;
+struct irq_info;
/**
* struct irq_common_data - per irq data shared by all irqchips
@@ -153,6 +154,9 @@ struct irq_common_data {
#ifdef CONFIG_GENERIC_IRQ_IPI
unsigned int ipi_offset;
#endif
+#ifdef CONFIG_XEN
+ struct irq_info *xen_irq_info;
+#endif
};
/**
@@ -849,6 +853,17 @@ struct cpumask *irq_data_get_effective_affinity_mask(struct irq_data *d)
}
#endif
+#ifdef CONFIG_XEN
+static inline struct irq_info *xen_get_irq_info(unsigned int irq)
+{
+ struct irq_data *d = irq_get_irq_data(irq);
+
+ return d ? d->common->xen_irq_info : NULL;
+}
+
+extern int xen_set_irq_info(unsigned int irq, struct irq_info *data);
+#endif
+
unsigned int arch_dynirq_lower_bound(unsigned int from);
int __irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 09d914e486a2..58d1cf60a4f8 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -163,6 +163,20 @@ struct irq_data *irq_get_irq_data(unsigned int irq)
}
EXPORT_SYMBOL_GPL(irq_get_irq_data);
+#ifdef CONFIG_XEN
+int xen_set_irq_info(unsigned int irq, struct irq_info *data)
+{
+ unsigned long flags;
+ struct irq_desc *desc = irq_get_desc_lock(irq, &flags, 0);
+
+ if (!desc)
+ return -EINVAL;
+ desc->irq_common_data.xen_irq_info = data;
+ irq_put_desc_unlock(desc, flags);
+ return 0;
+}
+#endif
+
static void irq_state_clr_disabled(struct irq_desc *desc)
{
irqd_clear(&desc->irq_data, IRQD_IRQ_DISABLED);
--
2.26.2
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 2/2] Xen: Rename irq_info structure
2020-08-21 7:15 ` [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data Sergey Temerkhanov
2020-08-21 7:15 ` [PATCH 1/2] Xen: Use a dedicated irq_info structure pointer Sergey Temerkhanov
@ 2020-08-21 7:15 ` Sergey Temerkhanov
2020-08-21 10:18 ` [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data Jürgen Groß
2 siblings, 0 replies; 19+ messages in thread
From: Sergey Temerkhanov @ 2020-08-21 7:15 UTC (permalink / raw)
To: xen-devel; +Cc: Sergey Temerkhanov
Rename irq_info structure to xen_irq_info to avoid namespace
conflicts
Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com>
---
drivers/xen/events/events_2l.c | 2 +-
drivers/xen/events/events_base.c | 60 ++++++++++++++--------------
drivers/xen/events/events_fifo.c | 5 ++-
drivers/xen/events/events_internal.h | 12 +++---
include/linux/irq.h | 10 +++--
kernel/irq/chip.c | 2 +-
6 files changed, 47 insertions(+), 44 deletions(-)
diff --git a/drivers/xen/events/events_2l.c b/drivers/xen/events/events_2l.c
index 8edef51c92e5..d4580db315b0 100644
--- a/drivers/xen/events/events_2l.c
+++ b/drivers/xen/events/events_2l.c
@@ -47,7 +47,7 @@ static unsigned evtchn_2l_max_channels(void)
return EVTCHN_2L_NR_CHANNELS;
}
-static void evtchn_2l_bind_to_cpu(struct irq_info *info, unsigned cpu)
+static void evtchn_2l_bind_to_cpu(struct xen_irq_info *info, unsigned int cpu)
{
clear_bit(info->evtchn, BM(per_cpu(cpu_evtchn_mask, info->cpu)));
set_bit(info->evtchn, BM(per_cpu(cpu_evtchn_mask, cpu)));
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index bcc3af399016..1e652ea8da87 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -152,7 +152,7 @@ int get_evtchn_to_irq(unsigned evtchn)
}
/* Constructors for packed IRQ information. */
-static int xen_irq_info_common_setup(struct irq_info *info,
+static int xen_irq_info_common_setup(struct xen_irq_info *info,
unsigned irq,
enum xen_irq_type type,
unsigned evtchn,
@@ -179,7 +179,7 @@ static int xen_irq_info_common_setup(struct irq_info *info,
static int xen_irq_info_evtchn_setup(unsigned irq,
unsigned evtchn)
{
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
return xen_irq_info_common_setup(info, irq, IRQT_EVTCHN, evtchn, 0);
}
@@ -189,7 +189,7 @@ static int xen_irq_info_ipi_setup(unsigned cpu,
unsigned evtchn,
enum ipi_vector ipi)
{
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
info->u.ipi = ipi;
@@ -203,7 +203,7 @@ static int xen_irq_info_virq_setup(unsigned cpu,
unsigned evtchn,
unsigned virq)
{
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
info->u.virq = virq;
@@ -219,7 +219,7 @@ static int xen_irq_info_pirq_setup(unsigned irq,
uint16_t domid,
unsigned char flags)
{
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
info->u.pirq.pirq = pirq;
info->u.pirq.gsi = gsi;
@@ -229,7 +229,7 @@ static int xen_irq_info_pirq_setup(unsigned irq,
return xen_irq_info_common_setup(info, irq, IRQT_PIRQ, evtchn, 0);
}
-static void xen_irq_info_cleanup(struct irq_info *info)
+static void xen_irq_info_cleanup(struct xen_irq_info *info)
{
set_evtchn_to_irq(info->evtchn, -1);
info->evtchn = 0;
@@ -259,7 +259,7 @@ int irq_from_virq(unsigned int cpu, unsigned int virq)
static enum ipi_vector ipi_from_irq(unsigned irq)
{
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
BUG_ON(info == NULL);
BUG_ON(info->type != IRQT_IPI);
@@ -269,7 +269,7 @@ static enum ipi_vector ipi_from_irq(unsigned irq)
static unsigned virq_from_irq(unsigned irq)
{
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
BUG_ON(info == NULL);
BUG_ON(info->type != IRQT_VIRQ);
@@ -279,7 +279,7 @@ static unsigned virq_from_irq(unsigned irq)
static unsigned pirq_from_irq(unsigned irq)
{
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
BUG_ON(info == NULL);
BUG_ON(info->type != IRQT_PIRQ);
@@ -317,7 +317,7 @@ static bool pirq_check_eoi_map(unsigned irq)
static bool pirq_needs_eoi_flag(unsigned irq)
{
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
BUG_ON(info->type != IRQT_PIRQ);
return info->u.pirq.flags & PIRQ_NEEDS_EOI;
@@ -326,7 +326,7 @@ static bool pirq_needs_eoi_flag(unsigned irq)
static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
{
int irq = get_evtchn_to_irq(chn);
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
BUG_ON(irq == -1);
#ifdef CONFIG_SMP
@@ -356,7 +356,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
static void xen_irq_init(unsigned irq)
{
- struct irq_info *info;
+ struct xen_irq_info *info;
#ifdef CONFIG_SMP
/* By default all event channels notify CPU#0. */
cpumask_copy(irq_get_affinity_mask(irq), cpumask_of(0));
@@ -418,7 +418,7 @@ static int __must_check xen_allocate_irq_gsi(unsigned gsi)
static void xen_free_irq(unsigned irq)
{
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_data(irq);
if (WARN_ON(!info))
return;
@@ -450,7 +450,7 @@ static void xen_evtchn_close(unsigned int port)
static void pirq_query_unmask(int irq)
{
struct physdev_irq_status_query irq_status;
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
BUG_ON(info->type != IRQT_PIRQ);
@@ -500,7 +500,7 @@ static void mask_ack_pirq(struct irq_data *data)
static unsigned int __startup_pirq(unsigned int irq)
{
struct evtchn_bind_pirq bind_pirq;
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
int evtchn = evtchn_from_irq(irq);
int rc;
@@ -553,7 +553,7 @@ static unsigned int startup_pirq(struct irq_data *data)
static void shutdown_pirq(struct irq_data *data)
{
unsigned int irq = data->irq;
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
unsigned evtchn = evtchn_from_irq(irq);
BUG_ON(info->type != IRQT_PIRQ);
@@ -578,7 +578,7 @@ static void disable_pirq(struct irq_data *data)
int xen_irq_from_gsi(unsigned gsi)
{
- struct irq_info *info;
+ struct xen_irq_info *info;
list_for_each_entry(info, &xen_irq_list_head, list) {
if (info->type != IRQT_PIRQ)
@@ -595,7 +595,7 @@ EXPORT_SYMBOL_GPL(xen_irq_from_gsi);
static void __unbind_from_irq(unsigned int irq)
{
int evtchn = evtchn_from_irq(irq);
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = irq_get_handler_data(irq);
if (info->refcnt > 0) {
info->refcnt--;
@@ -757,7 +757,7 @@ int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct msi_desc *msidesc,
int xen_destroy_irq(int irq)
{
struct physdev_unmap_pirq unmap_irq;
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
int rc = -ENOENT;
mutex_lock(&irq_mapping_update_lock);
@@ -795,7 +795,7 @@ int xen_irq_from_pirq(unsigned pirq)
{
int irq;
- struct irq_info *info;
+ struct xen_irq_info *info;
mutex_lock(&irq_mapping_update_lock);
@@ -849,7 +849,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
/* New interdomain events are bound to VCPU 0. */
bind_evtchn_to_cpu(evtchn, 0);
} else {
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
}
@@ -892,7 +892,7 @@ static int bind_ipi_to_irq(unsigned int ipi, unsigned int cpu)
}
bind_evtchn_to_cpu(evtchn, cpu);
} else {
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
WARN_ON(info == NULL || info->type != IRQT_IPI);
}
@@ -995,7 +995,7 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu, bool percpu)
bind_evtchn_to_cpu(evtchn, cpu);
} else {
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
WARN_ON(info == NULL || info->type != IRQT_VIRQ);
}
@@ -1099,7 +1099,7 @@ int bind_ipi_to_irqhandler(enum ipi_vector ipi,
void unbind_from_irqhandler(unsigned int irq, void *dev_id)
{
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
if (WARN_ON(!info))
return;
@@ -1128,7 +1128,7 @@ EXPORT_SYMBOL_GPL(xen_set_irq_priority);
int evtchn_make_refcounted(unsigned int evtchn)
{
int irq = get_evtchn_to_irq(evtchn);
- struct irq_info *info;
+ struct xen_irq_info *info;
if (irq == -1)
return -ENOENT;
@@ -1149,7 +1149,7 @@ EXPORT_SYMBOL_GPL(evtchn_make_refcounted);
int evtchn_get(unsigned int evtchn)
{
int irq;
- struct irq_info *info;
+ struct xen_irq_info *info;
int err = -ENOENT;
if (evtchn >= xen_evtchn_max_channels())
@@ -1257,7 +1257,7 @@ EXPORT_SYMBOL_GPL(xen_hvm_evtchn_do_upcall);
/* Rebind a new event channel to an existing irq. */
void rebind_evtchn_irq(int evtchn, int irq)
{
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
if (WARN_ON(!info))
return;
@@ -1406,7 +1406,7 @@ static void restore_pirqs(void)
{
int pirq, rc, irq, gsi;
struct physdev_map_pirq map_irq;
- struct irq_info *info;
+ struct xen_irq_info *info;
list_for_each_entry(info, &xen_irq_list_head, list) {
if (info->type != IRQT_PIRQ)
@@ -1545,7 +1545,7 @@ void xen_poll_irq(int irq)
/* Check whether the IRQ line is shared with other guests. */
int xen_test_irq_shared(int irq)
{
- struct irq_info *info = xen_get_irq_info(irq);
+ struct xen_irq_info *info = xen_get_irq_info(irq);
struct physdev_irq_status_query irq_status;
if (WARN_ON(!info))
@@ -1562,7 +1562,7 @@ EXPORT_SYMBOL_GPL(xen_test_irq_shared);
void xen_irq_resume(void)
{
unsigned int cpu;
- struct irq_info *info;
+ struct xen_irq_info *info;
/* New event-channel space is not 'live' yet. */
xen_evtchn_resume();
diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c
index 76b318e88382..7de34caa127a 100644
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -138,7 +138,7 @@ static void init_array_page(event_word_t *array_page)
array_page[i] = 1 << EVTCHN_FIFO_MASKED;
}
-static int evtchn_fifo_setup(struct irq_info *info)
+static int evtchn_fifo_setup(struct xen_irq_info *info)
{
unsigned port = info->evtchn;
unsigned new_array_pages;
@@ -186,7 +186,8 @@ static int evtchn_fifo_setup(struct irq_info *info)
return ret;
}
-static void evtchn_fifo_bind_to_cpu(struct irq_info *info, unsigned cpu)
+static void evtchn_fifo_bind_to_cpu(struct xen_irq_info *info,
+ unsigned int cpu)
{
/* no-op */
}
diff --git a/drivers/xen/events/events_internal.h b/drivers/xen/events/events_internal.h
index 50c2050a1e32..26d97a754318 100644
--- a/drivers/xen/events/events_internal.h
+++ b/drivers/xen/events/events_internal.h
@@ -30,7 +30,7 @@ enum xen_irq_type {
* IPI - IPI vector
* EVTCHN -
*/
-struct irq_info {
+struct xen_irq_info {
struct list_head list;
int refcnt;
enum xen_irq_type type; /* type */
@@ -59,8 +59,8 @@ struct evtchn_ops {
unsigned (*max_channels)(void);
unsigned (*nr_channels)(void);
- int (*setup)(struct irq_info *info);
- void (*bind_to_cpu)(struct irq_info *info, unsigned cpu);
+ int (*setup)(struct xen_irq_info *info);
+ void (*bind_to_cpu)(struct xen_irq_info *info, unsigned int cpu);
void (*clear_pending)(unsigned port);
void (*set_pending)(unsigned port);
@@ -78,7 +78,7 @@ extern const struct evtchn_ops *evtchn_ops;
extern int **evtchn_to_irq;
int get_evtchn_to_irq(unsigned int evtchn);
-struct irq_info *info_for_irq(unsigned irq);
+struct xen_irq_info *xen_get_irq_info(unsigned int irq);
unsigned cpu_from_irq(unsigned irq);
unsigned cpu_from_evtchn(unsigned int evtchn);
@@ -91,14 +91,14 @@ static inline unsigned xen_evtchn_max_channels(void)
* Do any ABI specific setup for a bound event channel before it can
* be unmasked and used.
*/
-static inline int xen_evtchn_port_setup(struct irq_info *info)
+static inline int xen_evtchn_port_setup(struct xen_irq_info *info)
{
if (evtchn_ops->setup)
return evtchn_ops->setup(info);
return 0;
}
-static inline void xen_evtchn_port_bind_to_cpu(struct irq_info *info,
+static inline void xen_evtchn_port_bind_to_cpu(struct xen_irq_info *info,
unsigned cpu)
{
evtchn_ops->bind_to_cpu(info, cpu);
diff --git a/include/linux/irq.h b/include/linux/irq.h
index e094d31916e2..0490d0c81820 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -123,7 +123,9 @@ enum {
struct msi_desc;
struct irq_domain;
-struct irq_info;
+#ifdef CONFIG_XEN
+ struct xen_irq_info;
+#endif
/**
* struct irq_common_data - per irq data shared by all irqchips
@@ -155,7 +157,7 @@ struct irq_common_data {
unsigned int ipi_offset;
#endif
#ifdef CONFIG_XEN
- struct irq_info *xen_irq_info;
+ struct xen_irq_info *xen_irq_info;
#endif
};
@@ -854,14 +856,14 @@ struct cpumask *irq_data_get_effective_affinity_mask(struct irq_data *d)
#endif
#ifdef CONFIG_XEN
-static inline struct irq_info *xen_get_irq_info(unsigned int irq)
+static inline struct xen_irq_info *xen_get_irq_info(unsigned int irq)
{
struct irq_data *d = irq_get_irq_data(irq);
return d ? d->common->xen_irq_info : NULL;
}
-extern int xen_set_irq_info(unsigned int irq, struct irq_info *data);
+extern int xen_set_irq_data(unsigned int irq, struct xen_irq_info *data);
#endif
unsigned int arch_dynirq_lower_bound(unsigned int from);
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 58d1cf60a4f8..427be895ec6e 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -164,7 +164,7 @@ struct irq_data *irq_get_irq_data(unsigned int irq)
EXPORT_SYMBOL_GPL(irq_get_irq_data);
#ifdef CONFIG_XEN
-int xen_set_irq_info(unsigned int irq, struct irq_info *data)
+int xen_set_irq_data(unsigned int irq, struct xen_irq_info *data)
{
unsigned long flags;
struct irq_desc *desc = irq_get_desc_lock(irq, &flags, 0);
--
2.26.2
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data
2020-08-21 7:15 ` [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data Sergey Temerkhanov
2020-08-21 7:15 ` [PATCH 1/2] Xen: Use a dedicated irq_info structure pointer Sergey Temerkhanov
2020-08-21 7:15 ` [PATCH 2/2] Xen: Rename irq_info structure Sergey Temerkhanov
@ 2020-08-21 10:18 ` Jürgen Groß
2020-08-21 11:19 ` Sergei Temerkhanov
2 siblings, 1 reply; 19+ messages in thread
From: Jürgen Groß @ 2020-08-21 10:18 UTC (permalink / raw)
To: Sergey Temerkhanov, xen-devel
On 21.08.20 09:15, Sergey Temerkhanov wrote:
> Use a dedicated pointer for IRQ data to avoid conflicts with some
> other parts of the kernel code which my use handler_data for their
> own purposes while still running on Xen
>
> Sergey Temerkhanov (2):
> Xen: Use a dedicated irq_info structure pointer
> Xen: Rename irq_info structure
>
> drivers/xen/events/events_2l.c | 2 +-
> drivers/xen/events/events_base.c | 80 +++++++++++++---------------
> drivers/xen/events/events_fifo.c | 5 +-
> drivers/xen/events/events_internal.h | 12 ++---
> include/linux/irq.h | 17 ++++++
> kernel/irq/chip.c | 14 +++++
> 6 files changed, 78 insertions(+), 52 deletions(-)
>
Did you see any specific problem where handler_data is written by
another component?
In case this is a real problem I don't think your approach will be
accepted, especially the IRQ subsystem maintainers probably won't
like it.
And please include the maintainers of the files you are modifying in
the recipients list of the patch(es).
Juergen
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data
2020-08-21 10:18 ` [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data Jürgen Groß
@ 2020-08-21 11:19 ` Sergei Temerkhanov
2020-08-21 12:17 ` Jürgen Groß
0 siblings, 1 reply; 19+ messages in thread
From: Sergei Temerkhanov @ 2020-08-21 11:19 UTC (permalink / raw)
To: Jürgen Groß; +Cc: xen-devel
>Did you see any specific problem where handler_data is written by
another component?
I've posted this series in the thread
https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg00957.html
where the problem is caused exactly by that behavior
>In case this is a real problem I don't think your approach will be accepted
Any comments/suggestions are welcome
Regards,
Sergey
On Fri, Aug 21, 2020 at 1:18 PM Jürgen Groß <jgross@suse.com> wrote:
>
> On 21.08.20 09:15, Sergey Temerkhanov wrote:
> > Use a dedicated pointer for IRQ data to avoid conflicts with some
> > other parts of the kernel code which my use handler_data for their
> > own purposes while still running on Xen
> >
> > Sergey Temerkhanov (2):
> > Xen: Use a dedicated irq_info structure pointer
> > Xen: Rename irq_info structure
> >
> > drivers/xen/events/events_2l.c | 2 +-
> > drivers/xen/events/events_base.c | 80 +++++++++++++---------------
> > drivers/xen/events/events_fifo.c | 5 +-
> > drivers/xen/events/events_internal.h | 12 ++---
> > include/linux/irq.h | 17 ++++++
> > kernel/irq/chip.c | 14 +++++
> > 6 files changed, 78 insertions(+), 52 deletions(-)
> >
>
> Did you see any specific problem where handler_data is written by
> another component?
>
> In case this is a real problem I don't think your approach will be
> accepted, especially the IRQ subsystem maintainers probably won't
> like it.
>
> And please include the maintainers of the files you are modifying in
> the recipients list of the patch(es).
>
>
> Juergen
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data
2020-08-21 11:19 ` Sergei Temerkhanov
@ 2020-08-21 12:17 ` Jürgen Groß
2020-08-21 20:07 ` Thomas Gleixner
0 siblings, 1 reply; 19+ messages in thread
From: Jürgen Groß @ 2020-08-21 12:17 UTC (permalink / raw)
To: Sergei Temerkhanov, Thomas Gleixner; +Cc: xen-devel
On 21.08.20 13:19, Sergei Temerkhanov wrote:
>> Did you see any specific problem where handler_data is written by
> another component?
>
> I've posted this series in the thread
> https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg00957.html
> where the problem is caused exactly by that behavior
>
>> In case this is a real problem I don't think your approach will be accepted
> Any comments/suggestions are welcome
Not sure if the IRQ maintainers agree with me, but I would add
a set_handler_data and get_handler_data function pointer to
struct irq_chip. If those are set I'd call them for writing/reading
handler_data instead doing it directly. Xen could then specify those
and add a field to its own handler data struct for storing the data
of the driver coming later.
Xen would need another accessor function for its own primary data,
of course.
Adding the IRQ maintainer as he might have an opinion here. :-)
Juergen
>
> Regards,
> Sergey
>
> On Fri, Aug 21, 2020 at 1:18 PM Jürgen Groß <jgross@suse.com> wrote:
>>
>> On 21.08.20 09:15, Sergey Temerkhanov wrote:
>>> Use a dedicated pointer for IRQ data to avoid conflicts with some
>>> other parts of the kernel code which my use handler_data for their
>>> own purposes while still running on Xen
>>>
>>> Sergey Temerkhanov (2):
>>> Xen: Use a dedicated irq_info structure pointer
>>> Xen: Rename irq_info structure
>>>
>>> drivers/xen/events/events_2l.c | 2 +-
>>> drivers/xen/events/events_base.c | 80 +++++++++++++---------------
>>> drivers/xen/events/events_fifo.c | 5 +-
>>> drivers/xen/events/events_internal.h | 12 ++---
>>> include/linux/irq.h | 17 ++++++
>>> kernel/irq/chip.c | 14 +++++
>>> 6 files changed, 78 insertions(+), 52 deletions(-)
>>>
>>
>> Did you see any specific problem where handler_data is written by
>> another component?
>>
>> In case this is a real problem I don't think your approach will be
>> accepted, especially the IRQ subsystem maintainers probably won't
>> like it.
>>
>> And please include the maintainers of the files you are modifying in
>> the recipients list of the patch(es).
>>
>>
>> Juergen
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data
2020-08-21 12:17 ` Jürgen Groß
@ 2020-08-21 20:07 ` Thomas Gleixner
2020-08-21 20:38 ` Sergei Temerkhanov
2020-08-25 3:14 ` Stefano Stabellini
0 siblings, 2 replies; 19+ messages in thread
From: Thomas Gleixner @ 2020-08-21 20:07 UTC (permalink / raw)
To: Jürgen Groß, Sergei Temerkhanov; +Cc: xen-devel
On Fri, Aug 21 2020 at 14:17, Jürgen Groß wrote:
> On 21.08.20 13:19, Sergei Temerkhanov wrote:
>>> Did you see any specific problem where handler_data is written by
>> another component?
>>
>> I've posted this series in the thread
>> https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg00957.html
>> where the problem is caused exactly by that behavior
>>
>>> In case this is a real problem I don't think your approach will be accepted
>> Any comments/suggestions are welcome
>
> Not sure if the IRQ maintainers agree with me, but I would add
> a set_handler_data and get_handler_data function pointer to
> struct irq_chip. If those are set I'd call them for writing/reading
> handler_data instead doing it directly. Xen could then specify those
> and add a field to its own handler data struct for storing the data
> of the driver coming later.
>
> Xen would need another accessor function for its own primary data,
> of course.
>
> Adding the IRQ maintainer as he might have an opinion here. :-)
Without seeing the patches, and no I'm not going to grab them from a web
archive, I'd say they are wrong :)
Fiddling in irqchip is wrong to begin with.
int irq_set_handler_data(unsigned int irq, void *data);
static inline void *irq_get_handler_data(unsigned int irq)
static inline void *irq_data_get_irq_handler_data(struct irq_data *d)
are accessors to handler_data. Am I missing something?
Thanks,
tglx
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data
2020-08-21 20:07 ` Thomas Gleixner
@ 2020-08-21 20:38 ` Sergei Temerkhanov
2020-08-22 0:16 ` Thomas Gleixner
2020-08-25 3:14 ` Stefano Stabellini
1 sibling, 1 reply; 19+ messages in thread
From: Sergei Temerkhanov @ 2020-08-21 20:38 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Jürgen Groß, xen-devel
On Fri, Aug 21, 2020 at 11:07 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> Fiddling in irqchip is wrong to begin with.
>
> int irq_set_handler_data(unsigned int irq, void *data);
> static inline void *irq_get_handler_data(unsigned int irq)
> static inline void *irq_data_get_irq_handler_data(struct irq_data *d)
>
> are accessors to handler_data. Am I missing something?
Well, the patches in question are meant to solve the issue discussed
in this thread:
https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg00957.html
All in all, the Dom0 kernel crashes due to a conflict between Xen and
GPIO pinctrl code both trying to use hander data to track some private
data. The patch series adds a separate pointer along with a few
functions for Xen. There may be other ideas on how to resolve this
issue though
Here are web archive :-) links:
https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg01144.html
https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg01145.html
Regards,
Sergey
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data
2020-08-21 20:38 ` Sergei Temerkhanov
@ 2020-08-22 0:16 ` Thomas Gleixner
0 siblings, 0 replies; 19+ messages in thread
From: Thomas Gleixner @ 2020-08-22 0:16 UTC (permalink / raw)
To: Sergei Temerkhanov; +Cc: Jürgen Groß, xen-devel
On Fri, Aug 21 2020 at 23:38, Sergei Temerkhanov wrote:
> On Fri, Aug 21, 2020 at 11:07 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>> Fiddling in irqchip is wrong to begin with.
>>
>> int irq_set_handler_data(unsigned int irq, void *data);
>> static inline void *irq_get_handler_data(unsigned int irq)
>> static inline void *irq_data_get_irq_handler_data(struct irq_data *d)
>>
>> are accessors to handler_data. Am I missing something?
>
> Well, the patches in question are meant to solve the issue discussed
> in this thread:
> https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg00957.html
> All in all, the Dom0 kernel crashes due to a conflict between Xen and
> GPIO pinctrl code both trying to use hander data to track some private
> data. The patch series adds a separate pointer along with a few
> functions for Xen. There may be other ideas on how to resolve this
> issue though
> Here are web archive :-) links:
> https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg01144.html
> https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg01145.html
As I said before, I'm not going to wade through a web archive simply
because it's tideous and I can't reply and quote properly.
Can you please just resend this series with the appropriate maintainers
and mailing lists in Cc which you should have done in the first place,
instead of offering me web links?
Just upfront, adding something just for XEN is wrong to begin with. This
is a conceptual problem and XEN is just triggering it, but the
argumentation must be on the concept level, not at the XEN level.
Without having looked at the patches, I bet that this new pointer has a
XEN name tag on it and the changelogs do not explain anything about the
conceptual problem the patches try to solve.
If I'm right, you might want to fix that before resending. If I'm wrong,
then I owe you a beer.
Thanks,
tglx
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data
2020-08-21 20:07 ` Thomas Gleixner
2020-08-21 20:38 ` Sergei Temerkhanov
@ 2020-08-25 3:14 ` Stefano Stabellini
2020-08-25 8:58 ` Thomas Gleixner
1 sibling, 1 reply; 19+ messages in thread
From: Stefano Stabellini @ 2020-08-25 3:14 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Jürgen Groß, Sergei Temerkhanov, xen-devel, sstabellini
[-- Attachment #1: Type: text/plain, Size: 2504 bytes --]
On Fri, 21 Aug 2020, Thomas Gleixner wrote:
> On Fri, Aug 21 2020 at 14:17, Jürgen Groß wrote:
> > On 21.08.20 13:19, Sergei Temerkhanov wrote:
> >>> Did you see any specific problem where handler_data is written by
> >> another component?
> >>
> >> I've posted this series in the thread
> >> https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg00957.html
> >> where the problem is caused exactly by that behavior
> >>
> >>> In case this is a real problem I don't think your approach will be accepted
> >> Any comments/suggestions are welcome
> >
> > Not sure if the IRQ maintainers agree with me, but I would add
> > a set_handler_data and get_handler_data function pointer to
> > struct irq_chip. If those are set I'd call them for writing/reading
> > handler_data instead doing it directly. Xen could then specify those
> > and add a field to its own handler data struct for storing the data
> > of the driver coming later.
> >
> > Xen would need another accessor function for its own primary data,
> > of course.
> >
> > Adding the IRQ maintainer as he might have an opinion here. :-)
>
> Without seeing the patches, and no I'm not going to grab them from a web
> archive, I'd say they are wrong :)
>
> Fiddling in irqchip is wrong to begin with.
>
> int irq_set_handler_data(unsigned int irq, void *data);
> static inline void *irq_get_handler_data(unsigned int irq)
> static inline void *irq_data_get_irq_handler_data(struct irq_data *d)
>
> are accessors to handler_data. Am I missing something?
Hi Thomas,
I think Juergen's suggestion was to use function pointers as accessors.
The underlying problem is that both Xen and GPIO want to use
handler_data.
Xen comes first and uses handler_data to handle Xen events
(drivers/xen/events/events_base.c:xen_irq_init).
Then, the GPIO driver probe function
(drivers/pinctrl/intel/pinctrl-baytrail.c:byt_gpio_probe) calls
gpiochip_set_chained_irqchip, which eventually calls
irq_set_chained_handler_and_data, overwriting handler_data without
checks.
Juergen's suggestion is to replace irq_set_handler_data and
irq_get_handler_data with function pointers.
Xen could install its own irq_set_handler_data and irq_get_handler_data
functions. The Xen implementation would take care of saving other
handler_data pointers on request: when the GPIO driver calls
irq_set_chained_handler_and_data it would end up calling the Xen
implementation of the set_handler_data function that would store the
GPIO pointer in a Xen struct somewhere.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data
2020-08-25 3:14 ` Stefano Stabellini
@ 2020-08-25 8:58 ` Thomas Gleixner
2020-08-25 13:49 ` Jürgen Groß
0 siblings, 1 reply; 19+ messages in thread
From: Thomas Gleixner @ 2020-08-25 8:58 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Jürgen Groß, Sergei Temerkhanov, xen-devel, sstabellini
On Mon, Aug 24 2020 at 20:14, Stefano Stabellini wrote:
> On Fri, 21 Aug 2020, Thomas Gleixner wrote:
>> are accessors to handler_data. Am I missing something?
> I think Juergen's suggestion was to use function pointers as accessors.
>
> The underlying problem is that both Xen and GPIO want to use
> handler_data.
>
> Xen comes first and uses handler_data to handle Xen events
> (drivers/xen/events/events_base.c:xen_irq_init).
>
> Then, the GPIO driver probe function
> (drivers/pinctrl/intel/pinctrl-baytrail.c:byt_gpio_probe) calls
> gpiochip_set_chained_irqchip, which eventually calls
> irq_set_chained_handler_and_data, overwriting handler_data without
> checks.
>
> Juergen's suggestion is to replace irq_set_handler_data and
> irq_get_handler_data with function pointers.
>
> Xen could install its own irq_set_handler_data and irq_get_handler_data
> functions. The Xen implementation would take care of saving other
> handler_data pointers on request: when the GPIO driver calls
> irq_set_chained_handler_and_data it would end up calling the Xen
> implementation of the set_handler_data function that would store the
> GPIO pointer in a Xen struct somewhere.
I don't think that's a good idea. The point is that we have an irq chip
which wants to have per interrupt data and then an interrupt request
which wants that as well.
Conceptually they are distinct. One belongs to the irq chip and one to
the handler.
So the straight forward solution is to switch XEN to use the
irqdesc::irq_data::chip_data instead of
irqdesc::irq_data_common::handler_data.
Something like the completely untested below.
Thanks,
tglx
---
drivers/xen/events/events_base.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -156,7 +156,7 @@ int get_evtchn_to_irq(evtchn_port_t evtc
/* Get info for IRQ */
struct irq_info *info_for_irq(unsigned irq)
{
- return irq_get_handler_data(irq);
+ return irq_get_chip_data(irq);
}
/* Constructors for packed IRQ information. */
@@ -377,7 +377,7 @@ static void xen_irq_init(unsigned irq)
info->type = IRQT_UNBOUND;
info->refcnt = -1;
- irq_set_handler_data(irq, info);
+ irq_set_chip_data(irq, info);
list_add_tail(&info->list, &xen_irq_list_head);
}
@@ -426,14 +426,14 @@ static int __must_check xen_allocate_irq
static void xen_free_irq(unsigned irq)
{
- struct irq_info *info = irq_get_handler_data(irq);
+ struct irq_info *info = irq_get_chip_data(irq);
if (WARN_ON(!info))
return;
list_del(&info->list);
- irq_set_handler_data(irq, NULL);
+ irq_set_chip_data(irq, NULL);
WARN_ON(info->refcnt > 0);
@@ -603,7 +603,7 @@ EXPORT_SYMBOL_GPL(xen_irq_from_gsi);
static void __unbind_from_irq(unsigned int irq)
{
evtchn_port_t evtchn = evtchn_from_irq(irq);
- struct irq_info *info = irq_get_handler_data(irq);
+ struct irq_info *info = irq_get_chip_data(irq);
if (info->refcnt > 0) {
info->refcnt--;
@@ -1108,7 +1108,7 @@ int bind_ipi_to_irqhandler(enum ipi_vect
void unbind_from_irqhandler(unsigned int irq, void *dev_id)
{
- struct irq_info *info = irq_get_handler_data(irq);
+ struct irq_info *info = irq_get_chip_data(irq);
if (WARN_ON(!info))
return;
@@ -1142,7 +1142,7 @@ int evtchn_make_refcounted(evtchn_port_t
if (irq == -1)
return -ENOENT;
- info = irq_get_handler_data(irq);
+ info = irq_get_chip_data(irq);
if (!info)
return -ENOENT;
@@ -1170,7 +1170,7 @@ int evtchn_get(evtchn_port_t evtchn)
if (irq == -1)
goto done;
- info = irq_get_handler_data(irq);
+ info = irq_get_chip_data(irq);
if (!info)
goto done;
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data
2020-08-25 8:58 ` Thomas Gleixner
@ 2020-08-25 13:49 ` Jürgen Groß
2020-08-25 15:22 ` [PATCH] xen/events: Use chip data for storing per IRQ XEN data pointer, Thomas Gleixner
0 siblings, 1 reply; 19+ messages in thread
From: Jürgen Groß @ 2020-08-25 13:49 UTC (permalink / raw)
To: Thomas Gleixner, Stefano Stabellini; +Cc: Sergei Temerkhanov, xen-devel
On 25.08.20 10:58, Thomas Gleixner wrote:
> On Mon, Aug 24 2020 at 20:14, Stefano Stabellini wrote:
>> On Fri, 21 Aug 2020, Thomas Gleixner wrote:
>>> are accessors to handler_data. Am I missing something?
>> I think Juergen's suggestion was to use function pointers as accessors.
>>
>> The underlying problem is that both Xen and GPIO want to use
>> handler_data.
>>
>> Xen comes first and uses handler_data to handle Xen events
>> (drivers/xen/events/events_base.c:xen_irq_init).
>>
>> Then, the GPIO driver probe function
>> (drivers/pinctrl/intel/pinctrl-baytrail.c:byt_gpio_probe) calls
>> gpiochip_set_chained_irqchip, which eventually calls
>> irq_set_chained_handler_and_data, overwriting handler_data without
>> checks.
>>
>> Juergen's suggestion is to replace irq_set_handler_data and
>> irq_get_handler_data with function pointers.
>>
>> Xen could install its own irq_set_handler_data and irq_get_handler_data
>> functions. The Xen implementation would take care of saving other
>> handler_data pointers on request: when the GPIO driver calls
>> irq_set_chained_handler_and_data it would end up calling the Xen
>> implementation of the set_handler_data function that would store the
>> GPIO pointer in a Xen struct somewhere.
>
> I don't think that's a good idea. The point is that we have an irq chip
> which wants to have per interrupt data and then an interrupt request
> which wants that as well.
>
> Conceptually they are distinct. One belongs to the irq chip and one to
> the handler.
>
> So the straight forward solution is to switch XEN to use the
> irqdesc::irq_data::chip_data instead of
> irqdesc::irq_data_common::handler_data.
Of course. I must have been blind not to spot chip_data to exist.
>
> Something like the completely untested below.
A short test showed no problems. Would you mind sending it as a proper
patch? You can add my
Reviewed-by: Juergen Gross <jgross@suse.com>
Juergen
>
> Thanks,
>
> tglx
> ---
> drivers/xen/events/events_base.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> --- a/drivers/xen/events/events_base.c
> +++ b/drivers/xen/events/events_base.c
> @@ -156,7 +156,7 @@ int get_evtchn_to_irq(evtchn_port_t evtc
> /* Get info for IRQ */
> struct irq_info *info_for_irq(unsigned irq)
> {
> - return irq_get_handler_data(irq);
> + return irq_get_chip_data(irq);
> }
>
> /* Constructors for packed IRQ information. */
> @@ -377,7 +377,7 @@ static void xen_irq_init(unsigned irq)
> info->type = IRQT_UNBOUND;
> info->refcnt = -1;
>
> - irq_set_handler_data(irq, info);
> + irq_set_chip_data(irq, info);
>
> list_add_tail(&info->list, &xen_irq_list_head);
> }
> @@ -426,14 +426,14 @@ static int __must_check xen_allocate_irq
>
> static void xen_free_irq(unsigned irq)
> {
> - struct irq_info *info = irq_get_handler_data(irq);
> + struct irq_info *info = irq_get_chip_data(irq);
>
> if (WARN_ON(!info))
> return;
>
> list_del(&info->list);
>
> - irq_set_handler_data(irq, NULL);
> + irq_set_chip_data(irq, NULL);
>
> WARN_ON(info->refcnt > 0);
>
> @@ -603,7 +603,7 @@ EXPORT_SYMBOL_GPL(xen_irq_from_gsi);
> static void __unbind_from_irq(unsigned int irq)
> {
> evtchn_port_t evtchn = evtchn_from_irq(irq);
> - struct irq_info *info = irq_get_handler_data(irq);
> + struct irq_info *info = irq_get_chip_data(irq);
>
> if (info->refcnt > 0) {
> info->refcnt--;
> @@ -1108,7 +1108,7 @@ int bind_ipi_to_irqhandler(enum ipi_vect
>
> void unbind_from_irqhandler(unsigned int irq, void *dev_id)
> {
> - struct irq_info *info = irq_get_handler_data(irq);
> + struct irq_info *info = irq_get_chip_data(irq);
>
> if (WARN_ON(!info))
> return;
> @@ -1142,7 +1142,7 @@ int evtchn_make_refcounted(evtchn_port_t
> if (irq == -1)
> return -ENOENT;
>
> - info = irq_get_handler_data(irq);
> + info = irq_get_chip_data(irq);
>
> if (!info)
> return -ENOENT;
> @@ -1170,7 +1170,7 @@ int evtchn_get(evtchn_port_t evtchn)
> if (irq == -1)
> goto done;
>
> - info = irq_get_handler_data(irq);
> + info = irq_get_chip_data(irq);
>
> if (!info)
> goto done;
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH] xen/events: Use chip data for storing per IRQ XEN data pointer,
2020-08-25 13:49 ` Jürgen Groß
@ 2020-08-25 15:22 ` Thomas Gleixner
2020-08-25 15:43 ` [PATCH] xen/events: Use chip data for storing per IRQ XEN data pointer Jürgen Groß
0 siblings, 1 reply; 19+ messages in thread
From: Thomas Gleixner @ 2020-08-25 15:22 UTC (permalink / raw)
To: Jürgen Groß
Cc: Sergei Temerkhanov, xen-devel, Stefano Stabellini, Roman Shaposhnik
XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt
XEN data pointer which contains XEN specific information.
handler data is meant for interrupt handlers and not for storing irq chip
specific information as some devices require handler data to store internal
per interrupt information, e.g. pinctrl/GPIO chained interrupt handlers.
This obviously creates a conflict of interests and crashes the machine
because the XEN pointer is overwritten by the driver pointer.
As the XEN data is not handler specific it should be stored in
irqdesc::irq_data::chip_data instead.
A simple sed s/irq_[sg]et_handler_data/irq_[sg]et_chip_data/ cures that.
Reported-by: Roman Shaposhnik <roman@zededa.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
Note: This probably wants a 'Cc: stable@' and a 'Fixes:' tag, but I
leave that as an exercise to the maintainers how far they want to move
that back.
---
drivers/xen/events/events_base.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -156,7 +156,7 @@ int get_evtchn_to_irq(evtchn_port_t evtc
/* Get info for IRQ */
struct irq_info *info_for_irq(unsigned irq)
{
- return irq_get_handler_data(irq);
+ return irq_get_chip_data(irq);
}
/* Constructors for packed IRQ information. */
@@ -377,7 +377,7 @@ static void xen_irq_init(unsigned irq)
info->type = IRQT_UNBOUND;
info->refcnt = -1;
- irq_set_handler_data(irq, info);
+ irq_set_chip_data(irq, info);
list_add_tail(&info->list, &xen_irq_list_head);
}
@@ -426,14 +426,14 @@ static int __must_check xen_allocate_irq
static void xen_free_irq(unsigned irq)
{
- struct irq_info *info = irq_get_handler_data(irq);
+ struct irq_info *info = irq_get_chip_data(irq);
if (WARN_ON(!info))
return;
list_del(&info->list);
- irq_set_handler_data(irq, NULL);
+ irq_set_chip_data(irq, NULL);
WARN_ON(info->refcnt > 0);
@@ -603,7 +603,7 @@ EXPORT_SYMBOL_GPL(xen_irq_from_gsi);
static void __unbind_from_irq(unsigned int irq)
{
evtchn_port_t evtchn = evtchn_from_irq(irq);
- struct irq_info *info = irq_get_handler_data(irq);
+ struct irq_info *info = irq_get_chip_data(irq);
if (info->refcnt > 0) {
info->refcnt--;
@@ -1108,7 +1108,7 @@ int bind_ipi_to_irqhandler(enum ipi_vect
void unbind_from_irqhandler(unsigned int irq, void *dev_id)
{
- struct irq_info *info = irq_get_handler_data(irq);
+ struct irq_info *info = irq_get_chip_data(irq);
if (WARN_ON(!info))
return;
@@ -1142,7 +1142,7 @@ int evtchn_make_refcounted(evtchn_port_t
if (irq == -1)
return -ENOENT;
- info = irq_get_handler_data(irq);
+ info = irq_get_chip_data(irq);
if (!info)
return -ENOENT;
@@ -1170,7 +1170,7 @@ int evtchn_get(evtchn_port_t evtchn)
if (irq == -1)
goto done;
- info = irq_get_handler_data(irq);
+ info = irq_get_chip_data(irq);
if (!info)
goto done;
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] xen/events: Use chip data for storing per IRQ XEN data pointer
2020-08-25 15:22 ` [PATCH] xen/events: Use chip data for storing per IRQ XEN data pointer, Thomas Gleixner
@ 2020-08-25 15:43 ` Jürgen Groß
2020-08-25 22:04 ` Roman Shaposhnik
0 siblings, 1 reply; 19+ messages in thread
From: Jürgen Groß @ 2020-08-25 15:43 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Sergei Temerkhanov, xen-devel, Stefano Stabellini, Roman Shaposhnik
On 25.08.20 17:22, Thomas Gleixner wrote:
> XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt
> XEN data pointer which contains XEN specific information.
>
> handler data is meant for interrupt handlers and not for storing irq chip
> specific information as some devices require handler data to store internal
> per interrupt information, e.g. pinctrl/GPIO chained interrupt handlers.
>
> This obviously creates a conflict of interests and crashes the machine
> because the XEN pointer is overwritten by the driver pointer.
>
> As the XEN data is not handler specific it should be stored in
> irqdesc::irq_data::chip_data instead.
>
> A simple sed s/irq_[sg]et_handler_data/irq_[sg]et_chip_data/ cures that.
>
> Reported-by: Roman Shaposhnik <roman@zededa.com>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Juergen Gross <jgross@suse.com>
> ---
> Note: This probably wants a 'Cc: stable@' and a 'Fixes:' tag, but I
> leave that as an exercise to the maintainers how far they want to move
> that back.
Will do. :-)
Thanks for the patch,
Juergen
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] xen/events: Use chip data for storing per IRQ XEN data pointer
2020-08-25 15:43 ` [PATCH] xen/events: Use chip data for storing per IRQ XEN data pointer Jürgen Groß
@ 2020-08-25 22:04 ` Roman Shaposhnik
0 siblings, 0 replies; 19+ messages in thread
From: Roman Shaposhnik @ 2020-08-25 22:04 UTC (permalink / raw)
To: Jürgen Groß
Cc: Thomas Gleixner, Sergei Temerkhanov, Xen-devel, Stefano Stabellini
On Tue, Aug 25, 2020 at 8:43 AM Jürgen Groß <jgross@suse.com> wrote:
>
> On 25.08.20 17:22, Thomas Gleixner wrote:
> > XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt
> > XEN data pointer which contains XEN specific information.
> >
> > handler data is meant for interrupt handlers and not for storing irq chip
> > specific information as some devices require handler data to store internal
> > per interrupt information, e.g. pinctrl/GPIO chained interrupt handlers.
> >
> > This obviously creates a conflict of interests and crashes the machine
> > because the XEN pointer is overwritten by the driver pointer.
> >
> > As the XEN data is not handler specific it should be stored in
> > irqdesc::irq_data::chip_data instead.
> >
> > A simple sed s/irq_[sg]et_handler_data/irq_[sg]et_chip_data/ cures that.
> >
> > Reported-by: Roman Shaposhnik <roman@zededa.com>
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>
> Reviewed-by: Juergen Gross <jgross@suse.com>
Tested-by: Roman Shaposhnik <roman@zededa.com>
Thank you everyone for coming up with the fix so quickly! I tested it out
and it appears to be functional with and without Xen.
Thanks,
Roman.
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2020-08-25 22:04 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-18 22:09 Xen 4.14.0 is busted on Dell 300x IoT Gateways Roman Shaposhnik
2020-08-18 22:20 ` Andrew Cooper
2020-08-18 22:34 ` Roman Shaposhnik
2020-08-21 1:39 ` Stefano Stabellini
2020-08-21 7:15 ` [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data Sergey Temerkhanov
2020-08-21 7:15 ` [PATCH 1/2] Xen: Use a dedicated irq_info structure pointer Sergey Temerkhanov
2020-08-21 7:15 ` [PATCH 2/2] Xen: Rename irq_info structure Sergey Temerkhanov
2020-08-21 10:18 ` [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data Jürgen Groß
2020-08-21 11:19 ` Sergei Temerkhanov
2020-08-21 12:17 ` Jürgen Groß
2020-08-21 20:07 ` Thomas Gleixner
2020-08-21 20:38 ` Sergei Temerkhanov
2020-08-22 0:16 ` Thomas Gleixner
2020-08-25 3:14 ` Stefano Stabellini
2020-08-25 8:58 ` Thomas Gleixner
2020-08-25 13:49 ` Jürgen Groß
2020-08-25 15:22 ` [PATCH] xen/events: Use chip data for storing per IRQ XEN data pointer, Thomas Gleixner
2020-08-25 15:43 ` [PATCH] xen/events: Use chip data for storing per IRQ XEN data pointer Jürgen Groß
2020-08-25 22:04 ` Roman Shaposhnik
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.