Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp166829pxk; Wed, 16 Sep 2020 00:48:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz7tSFqnnKiy6l7bFOft2Dh2LdaL8Ufag1G04lbEO5oDXnvsQ9laYo9LyDI992jRwrSrvM9 X-Received: by 2002:a17:906:3957:: with SMTP id g23mr25161695eje.24.1600242536507; Wed, 16 Sep 2020 00:48:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600242536; cv=none; d=google.com; s=arc-20160816; b=HFNhq0qCnF5QLHnM+oX1uSwzKSxut61EDQ0rGh+yzFxteqCHX+CxoVvM77gFQVJBJA D1Pnesbf8SaZ0ZEsCgQLIL7PDdOUVGKcQS3bjVruxRUxHp7TP/Fkwpc3+zfdWywa2pOF rS9ruNCQrMYdrgZ07IeWBM34Ss3S6U3Xxt7OQIENZkhKO2p2zJElhWWX7D/vQ/MITlpK 8BDzzMf+kRH9VHDTAk77W3E5pLcWUCUYXBvZkVpTwqgIqsl3KngOBhM2kMS/PJoSdqt7 izn8SNozicmTk3YcthewykNU+ZLR0ozZ+sUuMEtgqCvkmYK95//OGm+iitHm1F8XBQH2 j2pQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=76Bg72r+p2k9IbrpPzmK8vSWwjQMu3f6+BQBefJMooI=; b=D/jXR5CQr7vrOORyjCj4/zJpOtiW17ibc7CihAOtYcBoqYI+MjjT6EhPFqSVHfs3sO VeEhwA/TUDYxtOAeIQPUVlScGFi+4GNFiYxoag0e3jl9YLr4qgGPWCDRN2Z9+fUhh5F8 e85kMpWMm3SRGKhm293wi9/cTjToJ3bK3yrgcHdQp2rxZmuEJlR4X7c2bFyYz+PJsLi4 CigqKC8zChbgVYprIadR/KibeyXt7AIo7ZrZuIJ6/E9XtIs77Mgalsx35JLcmBxljDlW 2NfmlYssIBLNgAKRVO0oYbg7U8wkkwULCs48wEEfiNdNeWzPx3wcJRxwGUb0vrc7aoqN XVcg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hJVqQNKL; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i19si10923450edy.150.2020.09.16.00.48.33; Wed, 16 Sep 2020 00:48:56 -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=@redhat.com header.s=mimecast20190719 header.b=hJVqQNKL; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726502AbgIPHpF (ORCPT + 99 others); Wed, 16 Sep 2020 03:45:05 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:44703 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726314AbgIPHpD (ORCPT ); Wed, 16 Sep 2020 03:45:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600242302; 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: in-reply-to:in-reply-to:references:references; bh=76Bg72r+p2k9IbrpPzmK8vSWwjQMu3f6+BQBefJMooI=; b=hJVqQNKLXlJG59WQ8DIloHugEiAaJ7ZTvY9WWanZgQG2d+4hkKTzkBT0JJzQGuTasCC7yi MwPeg16MdKdv6uGG51s7L0ZDwTBZ2tILO2t0Ui+CcVNXtyEx7c5fEHZMSAxQIRtjUEkXwe eMBN3iDeP6gQBoCJcoBKcLqL5FVkC8U= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-125-OmJtXqokML-pa8glkHVIEA-1; Wed, 16 Sep 2020 03:45:00 -0400 X-MC-Unique: OmJtXqokML-pa8glkHVIEA-1 Received: by mail-wr1-f72.google.com with SMTP id o6so2215222wrp.1 for ; Wed, 16 Sep 2020 00:44:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=76Bg72r+p2k9IbrpPzmK8vSWwjQMu3f6+BQBefJMooI=; b=RKADLBAfLQjy6b1SB1a8klJw4R0sgBPv8ptdHQIUOfSrFT8dhW5riY+GJKZWoKcBq/ pKwx0G+BvWMlYgvexpNPfgNUXDmb4W+Ia4BZGO9y00nFQEJKdJ96Okg1C5Bjz2EebiUy a6iiD+4nXDXN06V/fsyv9fezMhjc/ANNtXkp7hKZHb3uj66NwfeN3LdO4wShiUlH0l72 4GmkNsxX5CqLLuwtj4dL3IXHqrAnAWUASVMPbBgsxrAyitq6rz4R8cqJxZmkW6qqxCuK RTbW7ZFihVSOh1WIs27HLuuXbGoRN7Sk2Awi9pPLocGFNQCyAoFu5n62sOfJRQ1jbIcF zGdA== X-Gm-Message-State: AOAM532vlf8m6mIXsDllI7aLoaJj9GUt1cS0rz03OOC1Kj+8NiJJQvcn LRDuV8J7F4/fdL8MFHE1vipwyzNPXYDDjz/LRxDoeYkAEmUS66ar2zlBvVGJE0EjkLah0R6P9QY PM34LeORDMpN+v0jQLryS9VjB X-Received: by 2002:adf:f5ce:: with SMTP id k14mr24488481wrp.286.1600242298766; Wed, 16 Sep 2020 00:44:58 -0700 (PDT) X-Received: by 2002:adf:f5ce:: with SMTP id k14mr24488461wrp.286.1600242298564; Wed, 16 Sep 2020 00:44:58 -0700 (PDT) Received: from vitty.brq.redhat.com (g-server-2.ign.cz. [91.219.240.2]) by smtp.gmail.com with ESMTPSA id h186sm3815236wmf.24.2020.09.16.00.44.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Sep 2020 00:44:57 -0700 (PDT) From: Vitaly Kuznetsov To: Wei Huang , "Dr. David Alan Gilbert" Cc: kvm@vger.kernel.org, Paolo Bonzini , Sean Christopherson , Wanpeng Li , Jim Mattson , Wei Huang , linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC 0/2] KVM: x86: allow for more CPUID entries In-Reply-To: <20200916034905.GA508748@weilap> References: <20200915154306.724953-1-vkuznets@redhat.com> <20200915165131.GC2922@work-vm> <20200916034905.GA508748@weilap> Date: Wed, 16 Sep 2020 09:44:55 +0200 Message-ID: <87k0wui2rs.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Wei Huang writes: > On 09/15 05:51, Dr. David Alan Gilbert wrote: >> * Vitaly Kuznetsov (vkuznets@redhat.com) wrote: >> > With QEMU and newer AMD CPUs (namely: Epyc 'Rome') the current limit for > > Could you elaborate on this limit? On Rome, I counted ~35 CPUID functions which > include Fn0000_xxxx, Fn4000_xxxx and Fn8000_xxxx. Some CPUID functions have indicies (e.g. 0x00000004, 0x8000001d, ...) and each existing index requires a separate entry. E.g. on my AMD EPYC 7401P host I can see: # cpuid -r -1 | wc -l 53 Hyper-V emulation accounts for 11 leaves (we don't currently set them all in QEMU but eventually we will). Also, we sometimes set both Intel and AMD cpuid leaves in QEMU (David can probably elaborate on which/why) and this all adds up. '80' seems to be an easy target to hit even with existing CPUs :-) -- Vitaly