search for: hvm_isa_irq_assert

Finally I got around to breaking up the similarly named monolithic patch that caused a regression shortly before the 4.2 release and got therefore reverted. This series consists of the broken up pieces that - according to my testing - don''t expose the reported lockup; the 7th will need debugging to understand what''s wrong there. 1: use RTC_* names instead of literal numbers 2:

Dear all: I have found a big bug on xen concerning time virtualization. Please let me show you the whole process: 1 Phenomenon when I run a JVM based program in IE browser in my Virtual Machine, I have found clearly that time at the right bottom corner in my VM gets more slower and slower. I studied the bug deeply, and found something below. 2 Xen vmx_vmexit_handler --> ......... -->

...te_irq(), we always choose IRQ0 rather than vlapic timer interrupt, because: 1) is_isa_irq_masked(v, 0) returns false due to vpic.imr.bit0 = 0; 2) the PIT''s pt->last_plt_gtime is less than vlapic timer''s -- at least I can see this on my hosts; However, in pt_update_irq() -> hvm_isa_irq_assert() -> vioapic_irq_positive_edge(), we do nothing but return at once because vioapic.redirtbl[2].mask = 1; Next, in vmx_intr_assist() -> hvm_vcpu_has_pending_irq(), we can''t inject vPIT interrupt because vlapic_accept_pic_intr() return false (because vlapic.lvt[LINT0].mask=1, and vlap...

...pu *v) if ( earliest_pt == NULL ) { spin_unlock(&v->arch.hvm_vcpu.tm_lock); - return; + return -1; } earliest_pt->irq_issued = 1; @@ -263,6 +263,17 @@ void pt_update_irq(struct vcpu *v) hvm_isa_irq_deassert(v->domain, irq); hvm_isa_irq_assert(v->domain, irq); } + + /* + * If periodic timer interrut is handled by lapic, its vector in + * IRR is returned and used to set eoi_exit_bitmap for virtual + * interrupt delivery case. Otherwise return -1 to do nothing. + */ + if ( vlapic_accept_pic_intr(v) &&am...