All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	rkrcmar@redhat.com, dvyukov@google.com,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] KVM: VMX: drop vmm_exclusive module parameter
Date: Wed, 21 Jun 2017 14:48:22 -0300	[thread overview]
Message-ID: <20170621174822.GR13640@kernel.org> (raw)
In-Reply-To: <20170310114713.7571-1-david@redhat.com>

Em Fri, Mar 10, 2017 at 12:47:13PM +0100, David Hildenbrand escreveu:
> vmm_exclusive=0 leads to KVM setting X86_CR4_VMXE always and calling
> VMXON only when the vcpu is loaded. X86_CR4_VMXE is used as an
> indication in cpu_emergency_vmxoff() (called on kdump) if VMXOFF has to be
> called. This is obviously not the case if both are used independtly.
> Calling VMXOFF without a previous VMXON will result in an exception.
> 
> In addition, X86_CR4_VMXE is used as a mean to test if VMX is already in
> use by another VMM in hardware_enable(). So there can't really be
> co-existance. If the other VMM is prepared for co-existance and does a
> similar check, only one VMM can exist. If the other VMM is not prepared
> and blindly sets/clears X86_CR4_VMXE, we will get inconsistencies with
> X86_CR4_VMXE.
> 
> As we also had bug reports related to clearing of vmcs with vmm_exclusive=0
> this seems to be pretty much untested. So let's better drop it.
> 
> While at it, directly move setting/clearing X86_CR4_VMXE into
> kvm_cpu_vmxon/off.

Oh well, I was using, as suggested by Alexander, this parameter to be
able to use Intel PT on the host on a Broadwell machine, i.e.:

  perf record -e intel_pt// usleep 1
  perf script

would show decoded Intel PT records, no more :-\ But I'm clueless about
KVM internals, so just reporting the change in behaviour for this very
specific use case.

Now I don't know if this is something that would make Intel PT be usable
on Broadwell machines but wouldn't be required with newer chips, will
test with a Kaby Lake i5 7500 when back at my home office...

- Arnaldo

  parent reply	other threads:[~2017-06-21 17:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-10 11:47 [PATCH RFC] KVM: VMX: drop vmm_exclusive module parameter David Hildenbrand
2017-03-14 20:30 ` Radim Krčmář
2017-04-18 13:30   ` Paolo Bonzini
2017-04-21  9:42 ` Paolo Bonzini
2017-06-21 17:48 ` Arnaldo Carvalho de Melo [this message]
2017-06-21 18:24   ` Radim Krčmář

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=20170621174822.GR13640@kernel.org \
    --to=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=david@redhat.com \
    --cc=dvyukov@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@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.