On Mon, 2012-06-18 at 14:17 +0300, Michael S. Tsirkin wrote: > On Mon, Jun 18, 2012 at 02:03:40PM +0300, Avi Kivity wrote: > > On 06/18/2012 01:55 PM, Michael S. Tsirkin wrote: > > > On Mon, Jun 18, 2012 at 01:14:13PM +0300, Avi Kivity wrote: > > >> On 06/18/2012 01:11 PM, Michael S. Tsirkin wrote: > > >> > > >> >> (vhost, > > >> >> msi-less ivshmem clone)? > > >> > > > >> > I guess vhost can poll eventfd and reinject an interrupt. > > >> > Of course to bypass qemu completely we also need to support reads over > > >> > ioeventfd somehow. > > >> > > > >> > > >> eventfd is not suitable for level triggered interrupts as far as I can > > >> tell. It's about passing edges, and level interrupts aren't. We need > > >> something like a pipe for communicating state (or just use KVM_IRQ_LINE). > > > > > > Just using KVM_IRQ_LINE won't be enough. > > > There's no software event when device deasserts the > > > line, and no stadard way for drivers to do this. > > > So kvm needs to trigger on some event to poll the real interrupt > > > state, to check whether it's ok to clear for the guest, > > > and forward it to userspace. > > > > This in turn only applies to real devices. Emulated devices of course > > know the state of the emulated interrupt line. > > Or to be more exact, real devices know the state of the line too. > It's the hyprvisor that doesn't know the state, because > of the abovementioned lack of standards, and because > the state control can be mapped directly into guest. Yes, exactly. > For example the hypervisor knows about virtio ISR > register so there's no problem. > > > Maybe we need different interfaces then. This interface is perhaps not as useful for anyone else as I was hoping, but is it the wrong interface? It still seems like a logical extension of irqfd, even if the use case is small. Thanks, 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
