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>
In-Reply-To: <a1ff3db1-1f5a-7bab-6c4b-f76e6d76d468@redhat.com>
From:   Jim Mattson <jmattson@google.com>
Date:   Mon, 2 Mar 2020 09:44:45 -0800
Message-ID: <CALMp9eQqFKnCLYGXdab-k=Q=h-H5x8VnV20F3HH9fDZTDuQcEQ@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 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.