On Thu, Jan 26, 2023 at 1:40 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > 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? Mainline isn't a problem. I'm more worried about 5.19 LTS. Thanks!
