RE: [PATCH v3 3/4] x86, apicv: add virtual interrupt delivery support

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

 



Gleb Natapov wrote on 2012-12-05:
> On Wed, Dec 05, 2012 at 02:16:52PM +0000, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2012-12-05:
>>> On Wed, Dec 05, 2012 at 03:43:41AM +0000, Zhang, Yang Z wrote:
>>>>>> @@ -5657,12 +5673,20 @@ static int vcpu_enter_guest(struct kvm_vcpu
>>>>> *vcpu)
>>>>>>  	}
>>>>>>  
>>>>>>  	if (kvm_check_request(KVM_REQ_EVENT, vcpu) || req_int_win) {
>>>>>> +		/* update archtecture specific hints for APIC
>>>>>> +		 * virtual interrupt delivery */
>>>>>> +		if (kvm_x86_ops->update_irq)
>>>>>> +			kvm_x86_ops->update_irq(vcpu);
>>>>>> +
>>>>>>  		inject_pending_event(vcpu);
>>>>>>  
>>>>>>  		/* enable NMI/IRQ window open exits if needed */
>>>>>>  		if (vcpu->arch.nmi_pending)
>>>>>>  			kvm_x86_ops->enable_nmi_window(vcpu);
>>>>>> -		else if (kvm_cpu_has_interrupt(vcpu) || req_int_win)
>>>>>> +		else if (kvm_apic_vid_enabled(vcpu)) {
>>>>>> +			if (kvm_cpu_has_extint(vcpu))
>>>>>> +				kvm_x86_ops->enable_irq_window(vcpu);
>>>>> 
>>>>> If RVI is non-zero, then interrupt window should not be enabled,
>>>>> accordingly to 29.2.2:
>>>>> 
>>>>> "If a virtual interrupt has been recognized (see Section 29.2.1), it will
>>>>> be delivered at an instruction boundary when the following conditions all
>>>>> hold: (1) RFLAGS.IF = 1; (2) there is no blocking by STI; (3) there is no
>>>>> blocking by MOV SS or by POP SS; and (4) the "interrupt-window exiting"
>>>>> VM-execution control is 0."
>>>> Right. Must check RVI here.
>>>> 
>>> Why? We request interrupt window here because there is ExtINT interrupt
>>> pending. ExtINT interrupt has a precedence over APIC interrupts (our
>>> current code is incorrect!), so we want vmexit as soon as interrupts are
>>> 
>>> allowed to inject ExtINT and we do not want virtual interrupt to be
>>> delivered. I think the (4) there is exactly for this situation.
>> One queston: kvm_cpu_has_extint() function check the interrupt from PIC. If
> PIC is working, APIC must in virtual wire mode. According to spec, when APIC is
> virtual wire mode, then APIC is totally bypassing. So apic_has_interrupt() and
> pic_has_interrupt() are mutually exclusive. If kvm_apic_has_interrupt() return
> true, then kvm_cpu_has_extint will never return true, and vice versa. Am I right?
> If answer is yes, then we don't check RVI here.
> According to what spec "when APIC is virtual wire mode, then APIC is
> totally bypassed"? SDP volume 3 section 10.8.2 says differently, but it
> gives priority to ExtINT interrupts. And we do it other way around
> currently, but your apicv patches actually do it correct by injecting
> ExtINT if it is asserted without considering apic state.
Thanks for correct me. I misunderstood the spec. :(
 
> --
> 			Gleb.
> --
> 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


Best regards,
Yang


--
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