Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp3807422pxy; Tue, 4 May 2021 10:19:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzS9z4ZzBP+Hl5zexarOjlhokk7J+VX30tI6lRQxdei0DZAync+gSkP5Ep0A/6xfIcN2fky X-Received: by 2002:a17:902:9a0a:b029:e6:bf00:8a36 with SMTP id v10-20020a1709029a0ab02900e6bf008a36mr27020778plp.51.1620148747938; Tue, 04 May 2021 10:19:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620148747; cv=none; d=google.com; s=arc-20160816; b=UPqIrs+xn4jcZA4sBc+QMb83aYUXSpSdYoPRzp5qMap+wY/p/aP2dETebE80Tce9ZL ZD8JOz8VXwAXWZUhYpc2MfgmLJ6eVw4KKTkpvrv+Wk1V9NLUDLpBLmSzhRIDy0O+1OuG p38XDKJDNcHPN2HQdHo12uEQoSeu8dG4X4X6KVEeAbWlqsrKUUool9jM8LT88d8o2bFv UFecNV3pxYHocTALIQdVavQj54K5YTmUZNgCdIDfXcMQF+0ExS77o3yDFzELg2bo+rty BPufh+QYSNW24O/hPGdCwXCEpFGI6FB409+KMwYnWjFA7KFAPuZyAmBB9T78fp+GE3/l Wetg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=vdkFREewlZcIDmDynEQ1WiTK28L5oQeFHQvdWFt20H8=; b=NWcKXzlQvH28AQE4RcFdXRwH1GMo4w/NsH68+eQPfqZprcPOMe1/Uj0lIyg70j8CCs TwvDabGL2rsB3yWaHNMr/78xEt3oRrmWYEvRcaWwDBuLaFJ8rXtW/iASYEaEPvl3+uBG 1qEKoEfi2OPKfTsQJF8TJJR/ieMTFUDQv1Wz7G+EpioUoJRyT1TGasKHUPTtqdxdMrX2 wJMaZTPxb8PDMwOR5B3sznnMZdXq1L+3jf+lq07mRHjPXTBPGtcYQIAYavzF/4ekpPN1 PxlM28oT+5fdmzP9TWkRoucjQS1+dM1TGn1AXc/Dr36rxczpaha2EaYFka1Z+luVjZot dDMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=sxCdv3gU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m136si3976060pga.183.2021.05.04.10.18.43; Tue, 04 May 2021 10:19:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=sxCdv3gU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231464AbhEDQxy (ORCPT + 99 others); Tue, 4 May 2021 12:53:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231607AbhEDQxx (ORCPT ); Tue, 4 May 2021 12:53:53 -0400 Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2DC69C061763 for ; Tue, 4 May 2021 09:52:58 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id c8-20020a9d78480000b0290289e9d1b7bcso8830762otm.4 for ; Tue, 04 May 2021 09:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vdkFREewlZcIDmDynEQ1WiTK28L5oQeFHQvdWFt20H8=; b=sxCdv3gUS81WcMO5HZwVF/YY/aTx9nyBxnp72jMDhHxZyPo8dExNRLRe1h6NxXBlMF owEnVU/qRjK/grqsNFswIwo4RYalfY8Q9BT68HxVIq40oX3IyJTxisXf+RWQnlh6ksBl 8SdZm2T5mo3K/W5I/O0LXTqtqkeiiNn2CxxT9Vt+ceX3uOQxiO7wonFbVriU//TlbdQQ dMKjYUY4W6MxXbGp5N2i0WA0yxZSBT3oJGmalOomTLWDKimjaT0vvCzdn/5nhsegpqSO PptP4XzsvIuul9jIuRXwBty0YwD1ttzYoy2OOyJjqlFRletHTLL2OLQhqHzi4cLGdbo6 1cTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vdkFREewlZcIDmDynEQ1WiTK28L5oQeFHQvdWFt20H8=; b=GVlvfwG6XVKETit8CDCjsWEArMg5S0v/hko77W/G4nDOd59Ex+LZI28ihBfZcWAssZ GqAIZj/UlWoZo7O2D3qMgcPohTOTahc9yKiLrkAmtajKnA285MQu6gzAC+p5ogRR3cho IZ1qlCkj/3gu1UWxWaJCVStfKhY9xa+S/09QorpmWbb0G5gijglC4zeaUZTj/FTbrm6/ rjDNYfxVySRxknYfU+MhvTxhd7qauap4DQYRdulqD0wDBQW9uuuBc8H3WlTGVmh3A969 jQxVChZnlKsUiC+BT6V7pcz529bTZ+ySUihpGCSHg8aR8Af8SaNOTzot9y7DAi+awWsU hxDg== X-Gm-Message-State: AOAM533c0vkxZaN+1XgoR/pcgLlUrLmIEaWXnQvLI9kQf4NkLUCim4Jt +GwNaw9vTge+G8J0UhcO0h9dx83tIIkTu6Is/qFw2g== X-Received: by 2002:a05:6830:16c8:: with SMTP id l8mr20047502otr.56.1620147177249; Tue, 04 May 2021 09:52:57 -0700 (PDT) MIME-Version: 1.0 References: <20210428172729.3551-1-valeriy.vdovin@virtuozzo.com> <0d68dbc3-8462-7763-fbad-f3b895fcf6e6@redhat.com> <63e54361-0018-ad3b-fb2b-e5dba6a0f221@redhat.com> <048b3f3a-379d-cff3-20b6-fc74dd12a98f@openvz.org> <514b5373-c07b-ad34-5fba-f8850faf6d68@redhat.com> In-Reply-To: From: Jim Mattson Date: Tue, 4 May 2021 09:52:46 -0700 Message-ID: Subject: Re: [PATCH v4] KVM: x86: Fix KVM_GET_CPUID2 ioctl to return cpuid entries count To: Alexander Graf Cc: Paolo Bonzini , "Denis V. Lunev" , Sean Christopherson , Valeriy Vdovin , LKML , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Shuah Khan , Aaron Lewis , Andrew Jones , Oliver Upton , Like Xu , kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 4, 2021 at 2:26 AM Alexander Graf wrote: > > > > On 04.05.21 10:21, Paolo Bonzini wrote: > > > > On 04/05/21 10:15, Denis V. Lunev wrote: > >> As far as I understand only some testing within kernel now. > >> Though we have plans to expose it for QAPI as the series > >> in QEMU > >> [PATCH 1/2] qapi: fix error handling for x-vz-query-cpu-model-cpuid > >> [PATCH 2/2] qapi: blacklisted x-vz-query-cpu-model-cpuid in tests > >> is not coming in a good way. > >> The idea was to avoid manual code rework in QEMU and > >> expose collected model at least for debug. > > > > KVM_GET_CPUID2 as a VM ioctl cannot expose the whole truth about CPUID > > either, since it doesn't handle the TSX_CTRL_CPUID_CLEAR bit. Given > > that QEMU doesn't need KVM_GET_CPUID2; it only needs to save whatever it > > passed to KVM_SET_CPUID2. > > What if we instead deflect CPUID into user space so it can emulate it in > whatever way it likes? Is the performance difference going to be > relevant? Are people still using cpuid as barrier these days? What else would they use (in ring 3 code)? Sure, serialize is coming in Sapphire Rapids, but it will be 20+ years before kvm drops support for CPUs without serialize. > > Alex > > > > Amazon Development Center Germany GmbH > Krausenstr. 38 > 10117 Berlin > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B > Sitz: Berlin > Ust-ID: DE 289 237 879 > >