From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [RFC PATCH] kvm: Extend irqfd to support level interrupts Date: Mon, 18 Jun 2012 08:32:15 -0600 Message-ID: <1340029935.24037.221.camel@bling.home> References: <20120616163230.15204.61075.stgit@bling.home> <4FDEE0A3.80900@redhat.com> <4FDEEC52.8080806@siemens.com> <4FDEF5CD.8090806@redhat.com> <20120618101156.GB23134@redhat.com> <4FDEFF75.6060104@redhat.com> <20120618105504.GA24051@redhat.com> <4FDF0B0C.3020009@redhat.com> <20120618111700.GC24051@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Jan Kiszka , "mtosatti@redhat.com" , "kvm@vger.kernel.org" To: "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45288 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752508Ab2FROcX (ORCPT ); Mon, 18 Jun 2012 10:32:23 -0400 In-Reply-To: <20120618111700.GC24051@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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