On Thu, 2012-06-28 at 19:27 +0300, Avi Kivity wrote: > On 06/24/2012 06:02 PM, Alex Williamson wrote: > > On Sun, 2012-06-24 at 15:56 +0300, Avi Kivity wrote: > >> On 06/23/2012 01:16 AM, Alex Williamson wrote: > >> > I think we're probably also going to need something like this. > >> > When running in non-accelerated qemu, we're going to have to > >> > create some kind of EOI notifier for drivers. VFIO can make > >> > additional improvements when running on KVM so it will probably > >> > make use of the KVM_IRQFD_LEVEL_EOI interface, but we don't > >> > want to have a generic EOI notifier in qemu that just stops > >> > working when kvm-ioapic is enabled. > >> > >> Why? > > > > Hmm, I must be missing something or not describing it correctly, because > > it seems obvious. > > I have not exhausted this quarter's quota of stupid questions yet. ;) > > If we create a dependency in qemu of needing to know > > when an eoi occurs and notifier a driver and have no way to fulfill that > > dependency when running on kvm... that'd be bad, right? I don't want to > > assume that every consumer of such an interface would prefer to make use > > of an irqfd. Not sure if that answers your question though. Thanks, > > I meant, what scenario do you have in mind where we want the EOI > notifier while running with kvm-irqchip enabled? Perhaps I phrased my > question a bit too tersely. Aha. Well, the v2 series really pulls eoifd in as more of a primary player and is now the only way to get EOI notification regardless of whether it's bound to a separate level irq source or used by qemu for the common userspace source. I don't know of any users that currently need EOI notification for the common userspace source id, but depending on where we land with whether KVM_IRQFD supports level interrupts, it may be vfio that needs it. Alex -- 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
