From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/3] RFC: virtual device as irq injection interface Date: Sun, 31 May 2009 23:30:48 +0300 Message-ID: <4A22E8F8.8020508@redhat.com> References: <20090531185841.GA10043@redhat.com> <4A22DD4B.8010703@redhat.com> <20090531201045.GA11327@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gregory Haskins , kvm@vger.kernel.org, mtosatti@redhat.com To: "Michael S. Tsirkin" Return-path: Received: from mx2.redhat.com ([66.187.237.31]:47186 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753537AbZEaUal (ORCPT ); Sun, 31 May 2009 16:30:41 -0400 In-Reply-To: <20090531201045.GA11327@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Michael S. Tsirkin wrote: >> Version N of irqfd actually had the kernel create the fd, due to >> concerns about eventfd's flexibility (thread wakeup vs function call). >> As it turned out these concerns were misplaced (well, we still want the >> call to happen in process context when available). >> > > I'm afraid there are deep lifetime issues there, and the recent patch > calling eventfd_fget seems to be just papering over the worst of them. > You'll have to be more specific. > >> I'd really like to stick with eventfd if we can solve all the problems >> there, rather than creating yet another interface. >> Especially if we want uio to communicate directly with kvm. >> > > Actually, current irqfd might not be able to handle assigned pci devices > because of the trick it does with set_irq(1)/set_irq(0) trick. > Guest drivers for pci devices likely assume the interrupt > is level. > Right. I'm willing to have some userspace mediation for level-triggered interrupts. It's a corner case anyway as we don't support shared interrupts on the host, and PCI level-triggered interrupts are very likely to be shared. > With virt devices, what we'd do is create a virt device that attaches to > uio driver. This would handle interrupts and everything else that needs > to live in kernel With irqfd, what we do is attach an eventfd to the MSI we're interested in. Given that eventfds are usable from userspace, we're adding a non-virt-specific interface to uio that serves kvm well. Both uio and kvm win. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.