Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp240540iob; Mon, 2 May 2022 18:13:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwS64sl0UxlnQTgFUHkF+FBmBqSzjMjx1tWLOeJfYld23wnpRSstMyGntR1tWtiLEE55KL6 X-Received: by 2002:a17:902:b7ca:b0:15c:df6a:be86 with SMTP id v10-20020a170902b7ca00b0015cdf6abe86mr14132200plz.70.1651540383226; Mon, 02 May 2022 18:13:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651540383; cv=none; d=google.com; s=arc-20160816; b=S09OC6ACoEbKUZc+giP45vDt1nCn1CyXNMkO55gKaZfmg+tqZ6YbKlyPkpoBv6u9ms q5RJ+1c7zvSiBNmf8dINvsFVbbXTaezH3Xc7NZCjMxGjdgSEEuyp7zfo4SojAMYDNXK2 ZRptH9+iTYOkYDjFWn85zdm5N9WzCEFojVWuwP60JX1hlnvgopQwjMaysXGHHPiR4bgH fKONh4h0FFVhMTVQrwbi5YfPSzxyF4VmqTwVtvhB+E4ekPvrpJSbotiGCCBq/LlDCgl7 VG48nZLPcflBD04WP90+7HPbuGKhaaKaDOdREaaYgFfngSaha9RLOTttW5wmyY1Eakon ZEaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=f98T4BJHfJan6nA7b2NKA9Mwn0L7MATFzgHNudByTF0=; b=PsGe/iVq++axMIBVcB8/Mcu1N4Q3NEy+ct3DMPWFP0WdGlNH1RUS3ymYvblRGowlC6 Uldmali7YYO5hkiPktfnZkqVmxr6vI7zBVfdIRMrdAqjBAmSME2iNTYYLPSGAyWeWu1A aMgQa7w25Hkit0PZkBbeBtZKfV80EOZYeW9TFSBKCgErXKN1817XhwgtlJB7TZmW5cpi uEl+P0p/17d26asbXHANW+l3MqD/TVq/haSFh6Gueg6/DSNfeScXVtiggVi6uwDsbGIV pb84qNAI27FAsNzBbPfD2jpr0HHGLvVfRn/CecxQNBQ7GxQ59yA+ElzJZ4TL0JmXEyv1 MP4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="i51/qOAN"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1: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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id g16-20020a1709029f9000b0015d04e10579si14377285plq.352.2022.05.02.18.13.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 May 2022 18:13:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="i51/qOAN"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1: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: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1095641603; Mon, 2 May 2022 17:53:57 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238556AbiD2T3U (ORCPT + 99 others); Fri, 29 Apr 2022 15:29:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234368AbiD2T3S (ORCPT ); Fri, 29 Apr 2022 15:29:18 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 325BF8164A for ; Fri, 29 Apr 2022 12:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651260357; 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; bh=f98T4BJHfJan6nA7b2NKA9Mwn0L7MATFzgHNudByTF0=; b=i51/qOANEsvU70Wr1A5ryCzOfT/75lQUkiew42TBOhEpmNmTLKzCRIQUn0Aca7fq6rehP+ kJLqAb7+5Y6zaCNKN3s9Rk4CX6AofjzpxaHIEqz6FcD7wr8TDLb2HoEbcG1oTc0msQ+4fv 017LYkv7XPhfJqodkmZtwyEt566Kilw= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-483-XS1Nj7v1OguIBsNbGBb46w-1; Fri, 29 Apr 2022 15:25:53 -0400 X-MC-Unique: XS1Nj7v1OguIBsNbGBb46w-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 516593834C02; Fri, 29 Apr 2022 19:25:53 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 34E7BC15D70; Fri, 29 Apr 2022 19:25:53 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: Maxim Levitsky Subject: [PATCH] KVM: x86: work around QEMU issue with synthetic CPUID leaves Date: Fri, 29 Apr 2022 15:25:53 -0400 Message-Id: <20220429192553.932611-1-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Synthesizing AMD leaves up to 0x80000021 caused problems with QEMU, which assumes the *host* CPUID[0x80000000].EAX is higher or equal to what KVM_GET_SUPPORTED_CPUID reports. This causes QEMU to issue bogus host CPUIDs when preparing the input to KVM_SET_CPUID2. It can even get into an infinite loop, which is only terminated by an abort(): cpuid_data is full, no space for cpuid(eax:0x8000001d,ecx:0x3e) To work around this, only synthesize those leaves if 0x8000001d exists on the host. The synthetic 0x80000021 leaf is mostly useful on Zen2, which satisfies the condition. Fixes: f144c49e8c39 ("KVM: x86: synthesize CPUID leaf 0x80000021h if useful") Reported-by: Maxim Levitsky Signed-off-by: Paolo Bonzini --- arch/x86/kvm/cpuid.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index b24ca7f4ed7c..598334ed5fbc 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -1085,12 +1085,21 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function) case 0x80000000: entry->eax = min(entry->eax, 0x80000021); /* - * Serializing LFENCE is reported in a multitude of ways, - * and NullSegClearsBase is not reported in CPUID on Zen2; - * help userspace by providing the CPUID leaf ourselves. + * Serializing LFENCE is reported in a multitude of ways, and + * NullSegClearsBase is not reported in CPUID on Zen2; help + * userspace by providing the CPUID leaf ourselves. + * + * However, only do it if the host has CPUID leaf 0x8000001d. + * QEMU thinks that it can query the host blindly for that + * CPUID leaf if KVM reports that it supports 0x8000001d or + * above. The processor merrily returns values from the + * highest Intel leaf which QEMU tries to use as the guest's + * 0x8000001d. Even worse, this can result in an infinite + * loop if said highest leaf has no subleaves indexed by ECX. */ - if (static_cpu_has(X86_FEATURE_LFENCE_RDTSC) - || !static_cpu_has_bug(X86_BUG_NULL_SEG)) + if (entry->eax >= 0x8000001d && + (static_cpu_has(X86_FEATURE_LFENCE_RDTSC) + || !static_cpu_has_bug(X86_BUG_NULL_SEG))) entry->eax = max(entry->eax, 0x80000021); break; case 0x80000001: -- 2.31.1