On Wed, Mar 20, 2013 at 05:03:19PM -0300, Marcelo Tosatti wrote: > On Wed, Mar 20, 2013 at 04:30:33PM -0300, Marcelo Tosatti wrote: > > On Sun, Mar 17, 2013 at 12:47:17PM +0200, Gleb Natapov wrote: > > > On Sun, Mar 17, 2013 at 11:45:34AM +0100, Jan Kiszka wrote: > > > > On 2013-03-17 09:47, Gleb Natapov wrote: > > > > > On Sat, Mar 16, 2013 at 09:49:07PM +0100, Jan Kiszka wrote: > > > > >> From: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> > > > > >> > > > > >> If the guest didn't take the last APIC timer interrupt yet and generates > > > > >> another one on top, e.g. via periodic mode, we do not block the VCPU > > > > >> even if the guest state is halted. The reason is that > > > > >> apic_has_pending_timer continues to return a non-zero value. > > > > >> > > > > >> Fix this busy loop by taking the IRR content for the LVT vector in > > > > >> apic_has_pending_timer into account. > > > > >> > > > > > Just drop coalescing tacking for lapic interrupt. After posted interrupt > > > > > will be merged __apic_accept_irq() will not longer return coalescing > > > > > information, so the code will be dead anyway. > > > > > > > > That requires the RTC decoalescing series to go first to avoid a > > > > regression, no? Then let's postpone this topic for now. > > > > > > > Yes, but decoalescing will work only for RTC :( > > > > Are you proposing to drop LAPIC interrupt reinjection? > > Since timer handling and injection is VCPU-local for LAPIC, > __apic_accept_irq can (and must) return coalesced information (cannot > drop LAPIC interrupt reinjection). > Why can't we drop LAPIC interrupt reinjection? Proposed posted interrupt patches do not properly check for interrupt coalescing even for VCPU-local injection. -- 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
