Re: [PATCH v2] KVM: x86: Do not return host topology information from KVM_GET_SUPPORTED_CPUID

From: Jim Mattson <jmattson@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	seanjc@google.com, stable@vger.kernel.org
Subject: Re: [PATCH v2] KVM: x86: Do not return host topology information from KVM_GET_SUPPORTED_CPUID
Date: Thu, 26 Jan 2023 08:06:16 -0800	[thread overview]
Message-ID: <CALMp9eTpbwQP3QsqpOBsDb0soLpsv9FZA=ivZUmf2GJgBxhfmw@mail.gmail.com> (raw)
In-Reply-To: <f322cce0-f83a-16d9-9738-f47f265b41d8@redhat.com>

On Thu, Jan 26, 2023 at 1:40 AM Paolo Bonzini <pbonzini@redhat.com> 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!