Hello, 

I am reporting a bare-metal Xen dom0 boot regression seen with Linux 6.18.52. 

On affected systems, Linux 6.18.51 boots successfully as Xen dom0 on bare metal, while Linux 6.18.52 consistently black-screens before dom0 userspace/networking comes up. 

#regzbot introduced: v6.18.51..v6.18.52
#regzbot title: ACPI processor/cpuidle lifecycle change breaks bare-metal Xen dom0 boot
#regzbot link: https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18447 

Tested results: 
 
  - Linux 6.18.51-r0, Xen dom0, bare metal: boots 
  - Linux 6.18.52-r0, Xen dom0, bare metal: black screen before userspace/network 
  - Linux 6.18.52-r0, Xen domU: boots 
  - Linux 6.18.52-r0 with Xenbus notifier change reverted: still fails 
  - Linux 6.18.52-r0 with only ACPI processor/cpuidle changes reverted: boots 
  - Linux 6.18.52-r0 with refined ACPI idle lifecycle patch: boots  

Affected hardware tested: 
 
  - Intel Core i7-4785T thin mini-ITX, 16 GB DDR3 
  - Intel N305 thin mini-ITX, 16 GB DDR5 
  - Supermicro / Intel Xeon E5-1650, 32 GB DDR3  

The successful boot used the regular Xen command line: 

multiboot2 /boot/xen.gz cpufreq=xen:performance
module2 /boot/vmlinuz-lts modules=loop,squashfs,sd-mod,usb-storage,xfs quiet
module2 /boot/initramfs-lts 

No IOMMU workaround, serial console parameter, debug parameter, storage workaround, or Xen command-line change was required. 

The regression was narrowed to ACPI processor/cpuidle changes between 6.18.51 and 6.18.52, specifically the idle-driver registration lifecycle. 

The working 6.18.51-style behavior registers the ACPI idle driver from acpi_processor_power_init() and unregisters it from acpi_processor_power_exit(). 

The failing 6.18.52 behavior registers the ACPI idle driver globally from acpi_processor_driver_init() before driver_register(). 

A first ACPI-only revert confirmed the regression source. A refined candidate patch was then prepared to preserve the working ACPI idle lifecycle while keeping unrelated 6.18.52 safety fixes, including: 
 
  - _LPI bounds checks 
  - cpufreq notifier cleanup on acpi_processor_driver_init() failure  

The refined candidate patch modifies only: 
   - drivers/acpi/processor_driver.c   - drivers/acpi/processor_idle.c   - include/acpi/processor.h  

It does not modify Xen, Xenbus, IOMMU, APIC, PCI/ASPM, intel_idle, syscore, USB, storage, XFS, networking, printk, or the cpuidle core API. 

The earlier cpuidle_disabled() workaround is not included. 

The refined patch has been rebuilt and boot-tested successfully as Xen dom0 on bare metal on TRINITY-EDGE. 

This issue is currently visible to Alpine users because the Alpine v3.24 stable repository contains: 

alpine-release 3.24.2-r0
linux-lts 6.18.52-r0 

Systems tracking Alpine 3.24 stable / latest-stable may therefore receive Linux 6.18.52 as the default LTS kernel. 

Attachments: 
 
  - revert-acpi-idle-registration-lifecycle.patch 
  - APKBUILD  

The original Alpine report is here: 

https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18447 

Please let me know if this should be submitted as a formal patch with Signed-off-by, or if there is a better upstream fix/dependency that should be backported instead. 

Regards,

Tony BONNIN