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 22:40:59 +0300 Message-ID: <4A22DD4B.8010703@redhat.com> References: <20090531185841.GA10043@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]:56172 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752637AbZEaTlD (ORCPT ); Sun, 31 May 2009 15:41:03 -0400 In-Reply-To: <20090531185841.GA10043@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Michael S. Tsirkin wrote: > As promised, here's a (compile-tested only) patchset that proposes > an alternative interrupt injection interface, not using eventfd. > > The idea here is that we give user the ability to create "virtual > device" file descriptors from kvm context, and bind them to in-kernel > drivers. One kind of such device would be virt_irq which let the user > inject interrupts. This seems to solve all potential lifetime > and locking issues because we control file_operations for both kvm fd > and the device(irq) fd. > > Another kind of device could be kernel-level virtio_net_host implementation > (which is really why I started writing this code). > > As an attempt to make virtual devices more useful, they actually use an > abstract virt_hypervisor interface. I have currently only implemented > it in kvm, but it will be possible to have lguest implement it as well, > and then lguest will be able to use e.g. in-kernel virtio-net. > > Let's discuss whether we want this, or eventfd, or both. > Certainly not both. 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'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. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.