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: Sun, 17 Jun 2012 15:38:57 -0600 Message-ID: <1339969137.24037.162.camel@bling.home> References: <20120616163230.15204.61075.stgit@bling.home> <20120617184451.GD21231@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: avi@redhat.com, mtosatti@redhat.com, kvm@vger.kernel.org, jan.kiszka@siemens.com To: "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:29477 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752447Ab2FQVjE (ORCPT ); Sun, 17 Jun 2012 17:39:04 -0400 In-Reply-To: <20120617184451.GD21231@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Sun, 2012-06-17 at 21:44 +0300, Michael S. Tsirkin wrote: > On Sat, Jun 16, 2012 at 10:34:39AM -0600, Alex Williamson wrote: > > I'm looking for opinions on this approach. For vfio device assignment > > we minimally need a way to get EOIs from the in-kernel irqchip out to > > userspace. Getting that out via an eventfd would allow us to bounce > > all level interrupts out to userspace, where we would de-assert the > > device interrupt in qemu and unmask the physical device. Ideally we > > could deassert the interrupt in KVM, which allows us to send the EOI > > directly to vfio. To do that, we need to use a new IRQ source ID so > > the guest sees the logical OR of qemu requested state and external > > device state. > > Given that yopu want to involve userspace anyway, why insist on irqfd > for this? You can simply use KVM_IRQ_LINE_STATUS from qemu, no? Well, actually I'd like to have a way to bypass userspace, which the combination of an irqfd + eventfd w/ deassert does. I'm not quite sure I understand how KVM_IRQ_LINE_STATUS would work for this. AIUI, that effectively gives us a way to post an interrupt AND let us know whether it was masked, coalesced, or delivered. So I'd have to poll by posting a potentially spurious interrupt and if it was spurious unmask the physical device and wait for a real interrupt? What am I missing, because that seems barely functional? Thanks, Alex