From mboxrd@z Thu Jan  1 00:00:00 1970
From: Gleb Natapov <gleb@redhat.com>
Subject: Re: [PATCH v2] KVM: x86: Rework INIT and SIPI handling
Date: Thu, 14 Mar 2013 14:12:29 +0200
Message-ID: <20130314121229.GN11223@redhat.com>
References: <5140662A.7010209@siemens.com>
 <20130314000850.GA4499@amt.cnet>
 <5141A326.3090500@siemens.com>
 <5141B4AC.2000708@siemens.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Marcelo Tosatti <mtosatti@redhat.com>, kvm <kvm@vger.kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:41170 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750989Ab3CNMMd (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 14 Mar 2013 08:12:33 -0400
Content-Disposition: inline
In-Reply-To: <5141B4AC.2000708@siemens.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Thu, Mar 14, 2013 at 12:29:48PM +0100, Jan Kiszka wrote:
> On 2013-03-14 11:15, Jan Kiszka wrote:
> >>>  
> >>> -	if (unlikely(vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED)) {
> >>> -		pr_debug("vcpu %d received sipi with vector # %x\n",
> >>> -			 vcpu->vcpu_id, vcpu->arch.sipi_vector);
> >>> -		kvm_lapic_reset(vcpu);
> >>> -		kvm_vcpu_reset(vcpu);
> >>> -		vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE;
> >>> -	}
> >>> -
> >>>  	vcpu->srcu_idx = srcu_read_lock(&kvm->srcu);
> >>>  	r = vapic_enter(vcpu);
> >>
> >> vmx_vcpu_reset overwrites vcpu->srcu_idx if ->vcpu_reset is called from
> >> within srcu section.
> > 
> > Indeed.
> > 
> > Do you know what the look over vmx_set_cr0 actually protects?
> 
> Found it: It's not actually protecting anything. enter_rmode is called,
> and that assumes that lock to be held. If enter_rmode faces an
> uninitialized tss, it drops the lock before calling vmx_set_tss_addr.
> 
> Well, I wonder if that is a good place to fix the TSS issue. Why not
> make that special case (lacking KVM_SET_TSS_ADDR before first KVM_RUN) a
> static jump key and check for it on KVM_RUN?
> 
Or finally break userspace that does not set it before calling kvm_run.
I haven't seen people complain about "kvm: KVM_SET_TSS_ADDR need to be
called before entering vcpu" warning in dmesg. Or create TSS mem slot at
0xfeffd000 during VM creation and destroy it if userspace overwrites it.

--
			Gleb.