Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <1582773688-4956-1-git-send-email-linmiaohe@huawei.com>
 <CALMp9eSaZ557-GaQUVXW6-ZrMkz8jxOC1S6QPk-EVNJ-f2pT5w@mail.gmail.com>
 <a1ff3db1-1f5a-7bab-6c4b-f76e6d76d468@redhat.com> <CALMp9eQqFKnCLYGXdab-k=Q=h-H5x8VnV20F3HH9fDZTDuQcEQ@mail.gmail.com>
 <e173c489-dee7-a86d-3ec4-6fe45938a2d8@redhat.com>
In-Reply-To: <e173c489-dee7-a86d-3ec4-6fe45938a2d8@redhat.com>
From:   Jim Mattson <jmattson@google.com>
Date:   Mon, 2 Mar 2020 10:30:22 -0800
Message-ID: <CALMp9eR9uanguked_O97BXMVGSE032m8QVsBP2qe2SS97j+qmg@mail.gmail.com>
Subject: Re: [PATCH v2] KVM: X86: deprecate obsolete KVM_GET_CPUID2 ioctl
To:     Paolo Bonzini <pbonzini@redhat.com>
Cc:     linmiaohe <linmiaohe@huawei.com>,
        =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Joerg Roedel <joro@8bytes.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H . Peter Anvin" <hpa@zytor.com>, kvm list <kvm@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        "the arch/x86 maintainers" <x86@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Mar 2, 2020 at 10:02 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 02/03/20 18:44, Jim Mattson wrote:
> > On Mon, Mar 2, 2020 at 9:09 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
> >>
> >> On 02/03/20 18:01, Jim Mattson wrote:
> >>>> And in fact, it's not used anywhere. So it should be
> >>>> deprecated.
> >>> I don't know how you can make the assertion that this ioctl is not
> >>> used anywhere. For instance, I see a use of it in Google's code base.
> >>
> >> Right, it does not seem to be used anywhere according to e.g. Debian
> >> code search but of course it can have users.
> >>
> >> What are you using it for?  It's true that cpuid->nent is never written
> >> back to userspace, so the ioctl is basically unusable unless you already
> >> know how many entries are written.  Or unless you fill the CPUID entries
> >> with garbage before calling it, I guess; is that what you are doing?
> >
> > One could use GET_CPUID2 after SET_CPUID2, to see what changes kvm
> > made to the requested guest CPUID information without telling you.
>
> Yeah, I think GET_CPUID2 with the same number of leaves that you have
> passed to SET_CPUID2 should work.

Having said that, it doesn't look like the method that invokes this
ioctl (in Google's code base) gets called from anywhere.