Marcelo Tosatti wrote on 2013-03-22: > On Thu, Mar 21, 2013 at 11:13:39PM +0200, Gleb Natapov wrote: >> On Thu, Mar 21, 2013 at 05:51:50PM -0300, Marcelo Tosatti wrote: >>>>>> But current PI patches do break them, thats my point. So we either >>>>>> need to revise them again, or drop LAPIC timer reinjection. Making >>>>>> apic_accept_irq semantics "it returns coalescing info, but only >>>>>> sometimes" is dubious though. >>>>> We may rollback to the initial idea: test both irr and pir to get coalescing > info. In this case, inject LAPIC timer always in vcpu context. So apic_accept_irq() > will return right coalescing info. >>>>> Also, we need to add comments to tell caller, apic_accept_irq() can >>>>> ensure the return value is correct only when caller is in target >>>>> vcpu context. >>>>> >>>> We cannot touch irr while vcpu is in non-root operation, so we will have >>>> to pass flag to apic_accept_irq() to let it know that it is called >>>> synchronously. While all this is possible I want to know which guests >>>> exactly will we break if we will not track interrupt coalescing for >>>> lapic timer. If only 2.0 smp kernels will break we can probably drop it. >>> >>> RHEL4 / RHEL5 guests. >> RHEL5 has kvmclock no? We should not break RHEL4 though. > > kvmclock provides no timer interrupt... either LAPIC or PIT must be used > with kvmclock. Ok, Here is the conclusion: -- According Marcelo's comments, RHEL4/RHEL5 rely on precise LAPIC timer injection. So LAPIC timer injection logic is necessary. --LAPIC timer injection always occurred in vcpu context, so it's safe to touch irr and pir for LAPIC timer injection. --We cannot touch virtual apic page while vcpu is in non-root operation, so the best solution is pass a flag to apic_accept_irq and check whether it's safe to touch vIRR according this flag. Right? 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
