All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <mlevitsk@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: work around QEMU issue with synthetic CPUID leaves
Date: Mon, 02 May 2022 09:25:41 +0300	[thread overview]
Message-ID: <a3868519e825075169e8f53620f18bdea9c6b5de.camel@redhat.com> (raw)
In-Reply-To: <54adc4a3-6b66-8ddf-db92-9630089da2dd@redhat.com>

On Sun, 2022-05-01 at 19:37 +0200, Paolo Bonzini wrote:
> 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.

Yes I see it, but it doesn't state that qemu doesn't do this to other leaves in the affected range.

I had to check the qemu source to verify this to be sure that checking for 0x8000001d
is enough.

Just a tiny minor nitpick though.

Best regards,
	Maxim Levitsky

> 
> Paolo
> 



      reply	other threads:[~2022-05-02  6:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-29 19:25 [PATCH] KVM: x86: work around QEMU issue with synthetic CPUID leaves Paolo Bonzini
2022-05-01 11:16 ` Maxim Levitsky
2022-05-01 17:37   ` Paolo Bonzini
2022-05-02  6:25     ` Maxim Levitsky [this message]

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=a3868519e825075169e8f53620f18bdea9c6b5de.camel@redhat.com \
    --to=mlevitsk@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.