Re: [PATCH v2] KVM: x86: Rework INIT and SIPI handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux