Re: [BUG] Xen Dom0 fails to boot with "nvme.poll_queues=24" and "dom0_max_vcpus=6 dom0_vcpus_pin"

[Jan Beulich <jbeulich@xxxxxxxx>]

On 09.10.2026 05:41, Egon Ojamaa wrote:
> Hello, Real human writing, not AI here ;)

Good to know such can still happen.

> #### Problem:
> 
> Booting Xen hypervisor with Linux Dom0.
> GRUB loads, Xen kernel messages load up to "Using 6 CPU"
> 
> # From this point:
> Next screen goes black and stays blank for 10+minutes.
> Have to force reboot and choose non XEN kernel booting option via GRUB.
> 
> # From this point expected behaviour without bug:
> Next screen goes black and stays so for 30-70sec and Dom0 kernel messages 
> appear,
> Next login is possible and system is running, "xl info" and other xl commands 
> function.
> 
> #### Cause:
> I spent 2 days rebooting to narrow this down..
> 
> This happens if we set both settings same time:
> NVME io polling and XEN kernel CPU limits, via default grub configs:
> 
> GRUB_CMDLINE_LINUX_DEFAULT="nvme.poll_queues=24"
> 
> # Can also be set via /mnt/oldroot/etc/modprobe.d/nvme.conf
> # For proper polling setup nvme.io_poll=1 should also be set,
> # but symptom already appears if we set only nvme.poll_queues=24
> 
> and
> 
> GRUB_CMDLINE_XEN_DEFAULT="dom0_max_vcpus=6 dom0_vcpus_pin"

Did you isolate which of the two options it actually is that causes the
problem, or whether it needs to be both together? Also, is 6 a necessary
(exact) precondition to the issue occurring?

> Sadly not my personal system, so I can not do further heavy testing on it.
> io polling does give very good performance boost to Gen5 NVME, and even Gen4.
> Sad we cant use it, as CPU pinning is more important for XEN hypervizor 
> system.
> 
> This has been also reported to launchpad.net:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170270

As was meanwhile also indicated in that report: What's completely missing
here, but very likely necessary for further analysis, are logs. That may
also help establishing whether it's the kernel (driver) that's hung, or
whether the system as a whole (i.e. Xen) is stuck. If nothing else in the
log has any indication either way, issuing a debug key (for starters just
'h', later maybe others) may help telling one from the other. If issuing
debug keys isn't possible anymore, try adding "watchdog" to the Xen
command line.

Jan