public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: unlisted-recipients:; (no To-header on input)
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	Gleb Natapov <gleb@redhat.com>, kvm <kvm@vger.kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v2] KVM: VMX: Do not overwrite vcpu->srcu_idx in vmx_vcpu_reset
Date: Fri, 15 Mar 2013 08:09:17 +0100	[thread overview]
Message-ID: <5142C91D.7080708@web.de> (raw)
In-Reply-To: <51422773.9010901@siemens.com>

[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]

On 2013-03-14 20:39, Jan Kiszka wrote:
> vmx_vcpu_reset may now be called while already holding the srcu lock, so
> we may overwrite what was already saved there. Save and restore it.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> 
> Even if this should be unneeded, it looks more consistent. In any case,
> all versions on the table, pick what you prefer.
> 
>  arch/x86/kvm/vmx.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 958ac3a..7bc49ca 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -4117,6 +4117,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu)
>  {
>  	struct vcpu_vmx *vmx = to_vmx(vcpu);
>  	u64 msr;
> +	int idx;
>  
>  	vmx->rmode.vm86_active = 0;
>  
> @@ -4190,9 +4191,11 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu)
>  		vmcs_write16(VIRTUAL_PROCESSOR_ID, vmx->vpid);
>  
>  	vmx->vcpu.arch.cr0 = X86_CR0_NW | X86_CR0_CD | X86_CR0_ET;
> +	idx = vcpu->srcu_idx;
>  	vcpu->srcu_idx = srcu_read_lock(&vcpu->kvm->srcu);
>  	vmx_set_cr0(&vmx->vcpu, kvm_read_cr0(vcpu)); /* enter rmode */
>  	srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);
> +	vcpu->srcu_idx = idx;
>  	vmx_set_cr4(&vmx->vcpu, 0);
>  	vmx_set_efer(&vmx->vcpu, 0);
>  	vmx_fpu_activate(&vmx->vcpu);
> 

This cannot work either: I think we really need to drop the srcu lock
before calling vmx_set_tss_addr. But if we nest the lock, we may only
drop it once now in enter_rmode.

OK, I'll propose a patch to remove that TSS bug workaround from
enter_rmode. Will dig a bit in the archives as well to check which
version of qemu-kvm was actually exposing this.

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  reply	other threads:[~2013-03-15  7:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-14 14:52 [PATCH] KVM: VMX: Do not overwrite vcpu->srcu_idx in vmx_vcpu_reset Jan Kiszka
2013-03-14 15:00 ` Gleb Natapov
2013-03-14 15:03   ` Jan Kiszka
2013-03-14 15:08     ` Paolo Bonzini
2013-03-14 15:11       ` Gleb Natapov
2013-03-14 15:45         ` Paolo Bonzini
2013-03-14 15:11       ` Jan Kiszka
2013-03-14 19:14   ` Marcelo Tosatti
2013-03-14 19:20     ` Jan Kiszka
2013-03-14 19:39       ` [PATCH v2] " Jan Kiszka
2013-03-15  7:09         ` Jan Kiszka [this message]
2013-03-14 20:02       ` [PATCH] " Marcelo Tosatti

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=5142C91D.7080708@web.de \
    --to=jan.kiszka@web.de \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox