On Mon, Feb 25, 2013 at 09:01:02PM +0200, Gleb Natapov wrote:
> On Mon, Feb 25, 2013 at 08:56:07PM +0200, Avi Kivity wrote:
> > On Mon, Feb 25, 2013 at 7:43 PM, Gleb Natapov <gleb@xxxxxxxxxx> wrote:
> > >
> > >> > 3. Do not report KVM_IRQ_LINE_STATUS capability and move RTC to use EOI
> > >> > notifiers for interrupt reinjection. This requires us to add interface
> > >> > for reporting EOI to userspace. This is not in the scope of this
> > >> > patchset. Cons: need to introduce new interface (and the one that will
> > >> > not work on AMD BTW)
> > >> >
> > >> > Other ideas?
> > >>
> > >> 1. inject RTC interrupt
> > >> 2. not see EOI
> > >> 3. inject RTC interrupt
> > >> 4. due to 2, report coalesced
> > >>
> > > That's the 3 in my list, no?
> >
> >
> > No, this idea doesn't involve user interface changes. We still report
> > through KVM_IRQ_LINE_STATUS or whatever it's called.
> Interesting idea!
>
But do not see how to implement efficiently without interface change. The
idea is basically to register ACK notifier for RTC interrupt but terminate
it in the kernel instead of reporting to userspace. Kernel should know
somehow what GSI should it register ACK notifier for. There are couple
of solutions:
1. New interface to tell what GSI to track.
- Cons: KVM_IRQ_LINE_STATUS will stop working for old QEMUs that do
not use it. New special purpose API.
2. Register ACK notifier only for RTC.
- Cons: KVM_IRQ_LINE_STATUS will work only for RTC. This is the only
thing that use it currently, but such change will make it one
trick pony officially.
3. Register ACK notifiers for all edge interrupts in IOAPIC.
- Cons: with APICv edge interrupt does not require EOI to do vmexit.
Registering ACK notifiers for all of them will make them all
do vmexit.
4. Combinations of 1 and 3. Register ACK notifiers for all edge interrupts
in IOAPIC and provide API to drop unneeded notifiers.
- Cons: New special purpose API.
Thoughts?
--
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
