Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <54adc4a3-6b66-8ddf-db92-9630089da2dd@redhat.com>
Date:   Sun, 1 May 2022 19:37:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: [PATCH] KVM: x86: work around QEMU issue with synthetic CPUID
 leaves
Content-Language: en-US
To:     Maxim Levitsky <mlevitsk@redhat.com>, linux-kernel@vger.kernel.org,
        kvm@vger.kernel.org
References: <20220429192553.932611-1-pbonzini@redhat.com>
 <1dcfb3d243916a3957d5368c2298e3f8fd79a9f2.camel@redhat.com>
From:   Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <1dcfb3d243916a3957d5368c2298e3f8fd79a9f2.camel@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 5/1/22 13:16, Maxim Levitsky wrote:
>> +		 * 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.
>
> Very small nitpick: It might be useful to add a note that qemu does this only for the
> leaf 0x8000001d.

Yes, it's there: "QEMU thinks that it can query the host blindly for 
that CPUID leaf", "that" is 0x8000001d in the previous sentence.

Paolo