From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D6ED3C2D0E3 for ; Tue, 15 Sep 2020 22:21:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9403D208E4 for ; Tue, 15 Sep 2020 22:21:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LLEva9hW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727687AbgIOQ2J (ORCPT ); Tue, 15 Sep 2020 12:28:09 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:46021 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727454AbgIOPnR (ORCPT ); Tue, 15 Sep 2020 11:43:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600184596; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=S7LOvCl7XUVBU80Y/PU+FTVOH70oxm6JnXxMde/HKVE=; b=LLEva9hWSkYksK8FihM07TdSQcZklvlTOQpA+T2fUuK1hpZykRTeUdtSDU6gZstkduG2W3 p1wHp/AcpDx0LicFCwmP7xLy0y3LYP9Etrst9GCnjuMAa1/cjyyIqdwS0JWXcrJi5IRq6g JFkW/j492lmhRNz5Xi5xgUJ7NIAxdjY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-409-HNLXfCHwMlOI095IlUogdg-1; Tue, 15 Sep 2020 11:43:12 -0400 X-MC-Unique: HNLXfCHwMlOI095IlUogdg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BA9D2CF983; Tue, 15 Sep 2020 15:43:10 +0000 (UTC) Received: from vitty.brq.redhat.com (unknown [10.40.195.78]) by smtp.corp.redhat.com (Postfix) with ESMTP id 120A119D61; Tue, 15 Sep 2020 15:43:07 +0000 (UTC) From: Vitaly Kuznetsov To: kvm@vger.kernel.org, Paolo Bonzini Cc: Sean Christopherson , Wanpeng Li , Jim Mattson , "Dr . David Alan Gilbert" , Wei Huang , linux-kernel@vger.kernel.org Subject: [PATCH RFC 0/2] KVM: x86: allow for more CPUID entries Date: Tue, 15 Sep 2020 17:43:04 +0200 Message-Id: <20200915154306.724953-1-vkuznets@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org With QEMU and newer AMD CPUs (namely: Epyc 'Rome') the current limit for KVM_MAX_CPUID_ENTRIES(80) is reported to be hit. Last time it was raised from '40' in 2010. We can, of course, just bump it a little bit to fix the immediate issue but the report made me wonder why we need to pre- allocate vcpu->arch.cpuid_entries array instead of sizing it dynamically. This RFC is intended to feed my curiosity. Very mildly tested with selftests/kvm-unit-tests and nothing seems to break. I also don't have access to the system where the original issue was reported but chances we're fixing it are very good IMO as just the second patch alone was reported to be sufficient. Reported-by: Dr. David Alan Gilbert Vitaly Kuznetsov (2): KVM: x86: allocate vcpu->arch.cpuid_entries dynamically KVM: x86: bump KVM_MAX_CPUID_ENTRIES arch/x86/include/asm/kvm_host.h | 4 +-- arch/x86/kvm/cpuid.c | 55 ++++++++++++++++++++++++--------- arch/x86/kvm/x86.c | 1 + 3 files changed, 43 insertions(+), 17 deletions(-) -- 2.25.4