On Wed, 2022-03-16 at 10:04 +0100, Igor Mammedov wrote: > Well, I retested with the latest upstream kernel (both guest and host), > and adding kvm_enable_x2apic() is not sufficient as guest according > to your patches in kernel caps max APICID at 255 unless kvm-msi-ext-dest-id > is enabled. And attempt in enabling kvm-msi-ext-dest-id with kernel-irqchip > fails. Correctly so. We need the split irqchip to support kvm-msi-ext-dest-id which is why there's an explicity check for it. > So number of usable CPUs in guest stays at legacy level, leaving the rest > of CPUs in limbo. Yep, that's the guest operating system's choice. Not a qemu problem. Even if you have the split IRQ chip, if you boot a guest without kvm- msi-ext-dest-id support, it'll refuse to use higher CPUs. Or if you boot a guest without X2APIC support, it'll refuse to use higher CPUs. That doesn't mean a user should be *forbidden* from launching qemu in that configuration.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
