On Wed, Mar 16, 2022 at 10:37:49AM +0000, David Woodhouse wrote: > On Wed, 2022-03-16 at 05:56 -0400, Michael S. Tsirkin wrote: > > On Wed, Mar 16, 2022 at 09:37:07AM +0000, David Woodhouse wrote: > > > 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. > > Not entirely sure how to reconcile that with what Daniel said in > https://lore.kernel.org/qemu-devel/yi9btkzim3izs...@redhat.com/ which > was: > > > We've generally said QEMU should not reject / block startup of valid > > hardware configurations, based on existance of bugs in certain guest > > OS, if the config would be valid for other guest.
For sure, but is this a valid hardware configuration? That's really the question. > That said, I cannot point at a *specific* example of a guest which can > use the higher CPUs even when it can't direct external interrupts at > them. I worked on making Linux capable of it, as I said, but didn't > pursue that in the end. > > I *suspect* Windows might be able to do it, based on the way the > hyperv-iommu works (by cheating and returning -EINVAL when external > interrupts are directed at higher CPUs). > > -- MST
