On Wed, Mar 16, 2022 at 09:37:07AM +0000, David Woodhouse wrote: > 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. Well the issue with all these configs which kind of work but not the way they were specified is that down the road someone creates a VM with this config and then expects us to maintain it indefinitely. So yes, if we are not sure we can support something properly it is better to validate and exit than create a VM guests don't know how to treat. -- MST
