On 1/26/23 01:58, Jim Mattson wrote:
You wrote it yourself: any VMM must either populate the topology on its
own, or possibly fill it with zeros. Returning a value that is
extremely unlikely to be used is worse in pretty much every way (apart
from not breaking your VMM, of course).
I've complained about this particular ioctl more than I can remember.
This is just one of its many problems.
I agree. At the very least it should have been a VM ioctl.
With a total of six known users (QEMU, crosvm, kvmtool, firecracker,
rust-vmm, and the Google VMM), KVM is damned if it reverts the patch and
damned if it doesn't. There is a tension between fixing the one VMM
that was using KVM_GET_SUPPORTED_CPUID correctly and now breaks loudly,
and fixing 3-4 that were silently broken and are now fixed. I will
probably send a patch to crosvm, though.
The VMM being _proprietary_ doesn't really matter, however it does
matter to me that it is not _public_: it is only used within Google, and
the breakage is neither hard to fix in the VMM nor hard to temporarily
avoid by reverting the patch in the Google kernel.
Sadly, there isn't a single kernel involved. People running our VMM on
their desktops are going to be impacted as soon as this patch hits
that distro. (I don't know if I can say which distro that is.) So, now
we have to get the VMM folks to urgently accommodate this change and
get a new distribution out.
Ok, this is what is needed to make a more informed choice. To be clear,
this is _still_ not public (for example it's not ChromeOS), so there is
at least some control on what version of the VMM they use? Would it
make sense to buy you a few months by deferring this patch to Linux 6.3-6.5?
Thanks,
Paolo
