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
next prev parent 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).