qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Phil Dennis-Jordan <phil@philjordan.eu>
Cc: qemu-devel@nongnu.org, Richard Henderson <rth@twiddle.net>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH] x86-KVM: Supply TSC and APIC clock rates to guest like VMWare
Date: Wed, 18 Jan 2017 17:10:09 +0100	[thread overview]
Message-ID: <df1239e9-e520-3c17-60cd-ec497c19e23b@redhat.com> (raw)
In-Reply-To: <CAAibmn3SqnaEiM6NED=UyPNGp5j2ymgBxpRygpUzpLCNcL-X8g@mail.gmail.com>



On 18/01/2017 17:02, Phil Dennis-Jordan wrote:
> 
>     One issue is that the TSC frequency can change, for example on
>     migration.  Telling the guest about the TSC frequency makes little sense
>     if it can change.
> 
> That makes sense. Darwin can't handle changing TSC frequencies in any
> case, regardless of cpuid leaf 0x40000010. Do I deduce correctly from
> the following code (lines 967~977) that this bit inhibits migration
> intrinsically, so other than depending on it, I don't need to
> specifically disable migration for this option?

Correct.

>     So the leaf should be conditional on the INVTSC feature
>     (CPUID[0x80000007].EDX bit 8).  You can enable this unconditionally for
>     new machine types (i.e. making it true here, and turning it off in
>     include/hw/i386/pc.h's PC_COMPAT_2_8 macro), but only expose it if that
>     bit is also set.
> 
> Sorry, you've lost me here. Would you mind explaining in a little more
> detail? What would I be enabling unconditionally? (I'm getting lost on
> what the various 'this'/'that'/'it' are referring to.)

You enable vmware-cpuid-freq unconditionally.  But then you actually
publish 0x40000010 only if INVTSC is set.
> 
>     > +    if (cpu->vmware_clock_rates) {
> 
>     ^^ Here is where you should also check invtsc.
> 
>     > +        if (cpu->expose_kvm
> 
>     I think this should not depend on cpu->expose_kvm.  This is not a KVM
>     leaf, it's a vmware leaf; if it were a KVM leaf, it would obey kvm_base.
>      Of course checking kvm_base is still a good idea, to avoid stomping on
>     Hyper-V's CPUID space.
> 
> Hmm, my thinking here is that leaf 0x40000000 only is published if kvm
> or Hyper-V is exposed. Without 0x40000000, Darwin won't find 0x40000010.

Of course you're right, but please add a comment like this:

	/* Guests depend on 0x40000000 to detect this, so do not expose
	 * it unless that leaf is present.
	 */

Paolo

  reply	other threads:[~2017-01-18 16:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-18 14:24 [Qemu-devel] [PATCH] x86-KVM: Supply TSC and APIC clock rates to guest like VMWare Phil Dennis-Jordan
2017-01-18 15:05 ` Paolo Bonzini
2017-01-18 15:23   ` Eduardo Habkost
2017-01-18 16:02   ` Phil Dennis-Jordan
2017-01-18 16:10     ` Paolo Bonzini [this message]
2017-01-18 16:16       ` Phil Dennis-Jordan
2017-01-18 16:22         ` Paolo Bonzini
2017-01-18 16:04   ` Phil Dennis-Jordan
2017-01-18 17:15     ` Eduardo Habkost

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=df1239e9-e520-3c17-60cd-ec497c19e23b@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=phil@philjordan.eu \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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;
as well as URLs for NNTP newsgroup(s).