From: Andre Przywara <andre.przywara@amd.com>
To: Avi Kivity <avi@redhat.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH 2/2] kvm/x86: remove unneeded substitute search for missing CPUID entries
Date: Thu, 31 Mar 2011 12:12:05 +0200 [thread overview]
Message-ID: <4D945375.4060407@amd.com> (raw)
In-Reply-To: <4D932F69.8070205@redhat.com>
Avi Kivity wrote:
> On 03/30/2011 03:01 PM, Andre Przywara wrote:
>> If KVM cannot find an exact match for a requested CPUID leaf, the
>> code will try to find the closest match instead of simply confessing
>> it's failure. The heuristic is on one hand wrong nowadays,
>> since it does not take the KVM CPUID leaves (0x400000xx) into
>> account. On the other hand the callers of this function can all deal
>> with the no-match situation. So lets remove this code, as it serves
>> no purpose.
>> This fixes a crash of newer Linux kernels as KVM guests on
>> AMD Bulldozer CPUs, where bogus values were returned in response to
>> a CPUID intercept.
>>
>>
>> @@ -4959,12 +4959,6 @@ struct kvm_cpuid_entry2 *kvm_find_cpuid_entry(struct kvm_vcpu *vcpu,
>> best = e;
>> break;
>> }
>> - /*
>> - * Both basic or both extended?
>> - */
>> - if (((e->function ^ function)& 0x80000000) == 0)
>> - if (!best || e->function> best->function)
>> - best = e;
>> }
>> return best;
>> }
>
>
> This behaviour is mandated by the spec (looking at the Intel one),
> though it is implemented incorrectly - should always return largest
> basic leaf, and ignore the kvm leaves.
But the spec says that this applies only if EAX is higher than the
largest supported leaf. The code as is checks whether KVM has an entry
in the cpuid "cache" for it, which is not the same. Especially this case
that hit me was a missing index entry, which should return 0.
The check for too large leaf numbers should be moved into
kvm_emulate_cpuid(). There is already some code in QEMU (cpu_x86_cpuid)
to handle this, but that path does not apply to KVM.
I will make a new version of this patch which replaces the old check
with a sane version in kvm_emulate_cpuid().
Thanks for pointing this out.
>
> I think the correct behaviour is:
>
> if (e->function < 10000 && (!best || e->function > best->function))
> best = e;
>
> We probably need a find_exact_cpuid_entry() that returns NULL if it
> doesn't find a match, for internal use.
As mentioned, this behavior only applies to the actual intercept case,
not to all users of kvm_find_cpuid_entry(). So I'd like to make this
check in the intercept code path and not in this function.
Regards,
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
next prev parent reply other threads:[~2011-03-31 10:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-30 13:01 [PATCH 1/2] kvm/x86: fix XSAVE bit scanning Andre Przywara
2011-03-30 13:01 ` [PATCH 2/2] kvm/x86: remove unneeded substitute search for missing CPUID entries Andre Przywara
2011-03-30 13:26 ` Avi Kivity
2011-03-30 13:33 ` Avi Kivity
2011-03-31 10:12 ` Andre Przywara [this message]
2011-03-31 10:32 ` Avi Kivity
2011-03-31 13:13 ` [PATCH 2/2] kvm/x86: move and fix substitue " Andre Przywara
2011-03-31 13:17 ` Avi Kivity
2011-03-31 14:50 ` Andre Przywara
2011-03-31 14:58 ` [PATCH 2/2 v3] " Andre Przywara
2011-04-03 12:32 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D945375.4060407@amd.com \
--to=andre.przywara@amd.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox