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
