Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp2465001ybf; Mon, 2 Mar 2020 09:10:11 -0800 (PST) X-Google-Smtp-Source: ADFU+vvMPVnh7Qk63ZFlZxHkA/1bmt9l7cs1fHsWRb/IODdDWgeWDKL8+R0RjNYO2vjczYDyyt0A X-Received: by 2002:a05:6830:1353:: with SMTP id r19mr156139otq.288.1583169010952; Mon, 02 Mar 2020 09:10:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583169010; cv=none; d=google.com; s=arc-20160816; b=qMTaxO0aAPPhY4mDveAvcPQ1LZKBNVEHSnoB10vh0gbdEmVZf/2nZ+G7Ufvs5icgdq YWTjXYbjM1r+7LJ/NI3kcAwMkmBbI0yns9D3x8NQFvkDFwiaDXT9tPNuKFa6pz2JIVZ9 /YPblovqZ70kqYP+uyHv22ERzwXMYon99Bv2Om6CGOeqnAlt6qaPRsfyHNmtJGH5CoQ7 E1hblKYDaZcLCja/oH9uRJWxu7eBtZ+/6SF8asq3bfyChwvhlyeSStFb2V6o3X9tl78Y K2OTSZMRGnu7f1SEAy6JSpRlWzQKblpawjfikwY3rvktoyzz5qvulue3VvKhlOZR+ao9 pbyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=WT1LxWtW4Alz7bMFxQVRaqlYT59rz8oUaocc8kmU1Ic=; b=Eh3jpyu3yPZOoP5YW+APrLYoEFyBdIM84tuoqmbhoXhjIExbHJeOwCtxgRSfdBH8ge FFvy942uMz83+8Wb+xeGVWuGGQ62g3mlIL4VhIq58OyhL1Mw5YWNM7FliBHfE56mYoIt isHsx5Rc6sPVbrEqV4TffOtz7wI9f7RstP1N4xVA/yumla2JSse9P9kdevimb8x+zeGO sV0APk+DV2vVCE7xp1oFZxkFtEuD6h+Po7PEG8wg9srXoPMr5t9Hhfdq+G4KP4XKuhDj SXa3c4QGpjaXxsgL8Lgrs8LrTwrkBX/lvoD7l2DL2IiGwBkADFVwtaUGRwmn4q7ZQkA5 /2Vg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=U6wne3gy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k1si6652433otn.181.2020.03.02.09.09.59; Mon, 02 Mar 2020 09:10:10 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=U6wne3gy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727401AbgCBRJp (ORCPT + 99 others); Mon, 2 Mar 2020 12:09:45 -0500 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:23958 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727196AbgCBRJo (ORCPT ); Mon, 2 Mar 2020 12:09:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583168983; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WT1LxWtW4Alz7bMFxQVRaqlYT59rz8oUaocc8kmU1Ic=; b=U6wne3gy171tjvEeoNus2sGOEQhq1FHb/BlqEmyS7SCPNJpRmf8lwn1vHaOCi6OfoH7aXJ eyyWGbHASuGWt8Pgdwo5MilSGZQ7AF2wNGPs+dkBxywVuaxrbuU5Uqkeu3Sty5mlQB+r2C IDXl9ufIkOOtICr1xtau9IGrt083vMM= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-488-A26cY9evMnO_LdMb30COfQ-1; Mon, 02 Mar 2020 12:09:42 -0500 X-MC-Unique: A26cY9evMnO_LdMb30COfQ-1 Received: by mail-wm1-f72.google.com with SMTP id f207so458wme.6 for ; Mon, 02 Mar 2020 09:09:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WT1LxWtW4Alz7bMFxQVRaqlYT59rz8oUaocc8kmU1Ic=; b=uZglfUzgBxAtdvlsntyKMfg7JqZCyWGJNxXMlTE9PjAWK8MgC2tl0ven/EzQ3oVl7I 2WJl9ewiissqvlpOHfKkzSCs0aRVdehtOWYi7atqXvvF7/9ftBS+j5cNdUDc1Cr6S3jb qbSL2i5W9R1OTZNPOdZRXWhKUVczvSbn1XSkkc1FSmpauPTF7otB6WMIhvZOgC3jfmJu Sguo2Bqm7eE7/aMMWzKQIjV4sDTFdFJsNtr97NbQDsa26zcMIirP6WH47nQ8Anf522Zd PNHZUNaDNpMNMYuhfqB+itzdLhvYXvBDcJOHViSq7oZNC0UhCSl9i85xzoJ2tPW3TdQt 2tfw== X-Gm-Message-State: ANhLgQ3iUu7JSsI4L7lPkwIBFGJTaDNQO1YEsTbJBVsjT9H7CoVUYlSg bb2PAre72DF3nhMZiqBMPKzG4EBWpz+oIc0JYU0KqqDIuPM+0LbapiTAG8gWV+P1ORB86/guBfu nP8GrobV5DbPClB+CPM7CKySC X-Received: by 2002:adf:ebca:: with SMTP id v10mr529131wrn.307.1583168980823; Mon, 02 Mar 2020 09:09:40 -0800 (PST) X-Received: by 2002:adf:ebca:: with SMTP id v10mr529103wrn.307.1583168980629; Mon, 02 Mar 2020 09:09:40 -0800 (PST) Received: from [192.168.178.40] ([151.30.85.6]) by smtp.gmail.com with ESMTPSA id s15sm29549483wrp.4.2020.03.02.09.09.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2020 09:09:40 -0800 (PST) Subject: Re: [PATCH v2] KVM: X86: deprecate obsolete KVM_GET_CPUID2 ioctl To: Jim Mattson , linmiaohe Cc: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , kvm list , LKML , the arch/x86 maintainers References: <1582773688-4956-1-git-send-email-linmiaohe@huawei.com> From: Paolo Bonzini Message-ID: Date: Mon, 2 Mar 2020 18:09:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? Paolo