From: "Michael S. Tsirkin" Subject: Re: [PATCH 0/2] eventfd: new EFD_STATE flag Date: Sun, 23 Aug 2009 16:36:21 +0300 Message-ID: <20090823133620.GA12841@redhat.com> References: <20090820155655.GA8764@redhat.com> <4A8D8A28.2050004@redhat.com> <20090820175540.GA9232@redhat.com> <4A8D90BB.2030506@redhat.com> <20090820182847.GB9282@redhat.com> <4A913DA9.1020403@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Davide Libenzi , gleb@redhat.com, kvm@vger.kernel.org, Linux Kernel Mailing List To: Avi Kivity Return-path: Content-Disposition: inline In-Reply-To: <4A913DA9.1020403@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Sun, Aug 23, 2009 at 04:01:29PM +0300, Avi Kivity wrote: > On 08/20/2009 09:28 PM, Michael S. Tsirkin wrote: >>>> I thought the point was to move assigned devices out of KVM? >>>> >>>> >>> Grr. Forgot about that. >>> >>> That's much more important. >>> >> Looks like we'll have do with a separate char device or >> something? >> > > We can still tunnel it through userspace. More important here is realization that eventfd is a mutex/semaphore implementation, not a generic event reporting interface as we are trying to use it. > Most assigned devices will > have MSI. uio can signal the eventfd when the level changes, qemu can > read the level and write it to kvm. > -- > error compiling committee.c: too many arguments to function