IRQ handling still assigned to isolated CPUs

[anubias]

Describe the bug
Even if the isolcpu is configured to a subset of available processors, after fresh-installing the SEAPATH hypervisor, the kernel command line looks like this:

BOOT_IMAGE=/boot/vmlinuz-6.12.48+deb13-rt-amd64 root=/dev/mapper/vg1-root ro ipv6.disable=1 efi=runtime fsck.mode=force fsck.repair=yes default_hugepagesz=1G hugepagesz=1G hugepages=6 skew_tick=1 tsc=reliable rcupdate.rcu_normal_after_boot=1 isolcpus=managed_irq,domain,4-N intel_pstate=disable nosoftlockup nohz=on nohz_full=4-N rcu_nocbs=4-N irqaffinity=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 processor.max_cstate=1 intel_idle.max_cstate=1 cpufreq.default_governor=performance rcu_nocb_poll

Please note the irqaffinity=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15, which seems to collide with isolcpus=managed_irq,domain,4-N

To Reproduce
Just have a fresh install of the hypervisor, with some isolated CPUs configured and check the cat /proc/cmdline output.

Expected behavior
The IRQ handling should be restricted ONLY to the non-isolated CPUs in the system.

SEAPATH distribution
Debian Trixie standalone

SEAPATH version
Commit SHA: 496c7e3

[eroussy]

Hi

This is also present on the Debian CI, so it also impacts the main branch.
I've tracked the problem to tuned not being capable of understanding the "N" value in isolcpus

A quick and easy work around is to change the isolcpus variable in the inventory and put your exact maximum CPU number. For example isolcpus: "4-15" on a 16 cores machine.
Then re-run the seapath-setup-main.yaml playbook.

[eroussy]

Issue opened in tuned redhat-performance/tuned#831

[eroussy]

Also, note on the fact that this also affect Yocto: We still have irq not correctly scheduled on Yocto.
But because tuned is not installed, I bet the root cause is irqbalance. IMO we should get rid of irqbalance and pass irqaffinity by command line