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

Re: [Xen-devel] [PATCH] X86/vmx: Dump PIR and vIRR before ASSERT()

On Tue, Feb 07, 2017 at 03:04:32AM -0700, Jan Beulich wrote:
>>>> On 07.02.17 at 07:48, <xuquan8@xxxxxxxxxx> wrote:
>> Some comment from QEMU/KVM code, in <linux-kernel>/arch/x86/kvm/lapic.c,
>> int kvm_lapic_find_highest_irr(struct kvm_vcpu *vcpu)
>> {
>>      /* This may race with setting of irr in __apic_accept_irq() and
>>       * value returned may be wrong, but kvm_vcpu_kick() in __apic_accept_irq
>>       * will cause vmexit immediately and the value will be recalculated
>>       * on the next vmentry.
>>       */
>> ...
>> }
>> I am afraid, there may be a similar race with setting of vIRR..
>I think this is unrelated: If another interrupt came in, the highest
>set bit in vIRR can only increase. Plus pt_update_irq(), before
>returning, calls vlapic_set_irq(), which ought to result in pt_vector's
>vIRR bit to be set (either directly or via setting its PIR bit). I.e. the
>highest priority interrupt should still have a vector >= pt_vector.

I have noticed that pt_vector was 0x38 and the hightest vector was 0x30
when the assertion failed. In the process of debugging pt_update_irq() 
when I was working on another feature, I noticed that 0x30 is always 
the vector of IRQ2. I suspect that the source of the periodic timer interrupt
is not lapic. If that, pt_update_irq() reads the vioapic entry twice,
one in hvm_isa_irq_assert() and the other in pt_irq_vector().
If guest changed the content in viopaic entry between the two read
(ie. change the vector from 0x30 to 0x38), the assertion would fail.
Do you think it is a reasonable explanation?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.