From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [RFC PATCH] kvm: Extend irqfd to support level interrupts Date: Mon, 18 Jun 2012 09:00:38 +0300 Message-ID: <20120618060037.GC1423@redhat.com> References: <20120616163230.15204.61075.stgit@bling.home> <20120617184451.GD21231@redhat.com> <1339969137.24037.162.camel@bling.home> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: avi@redhat.com, mtosatti@redhat.com, kvm@vger.kernel.org, jan.kiszka@siemens.com To: Alex Williamson Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60796 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751203Ab2FRGAm (ORCPT ); Mon, 18 Jun 2012 02:00:42 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Sun, Jun 17, 2012 at 04:15:44PM -0600, Alex Williamson wrote: > On Sun, Jun 17, 2012 at 3:38 PM, Alex Williamson > wrote: > > 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. =A0For vfio device as= signment > >> > we minimally need a way to get EOIs from the in-kernel irqchip o= ut to > >> > userspace. =A0Getting 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. =A0Idea= lly we > >> > could deassert the interrupt in KVM, which allows us to send the= EOI > >> > directly to vfio. =A0To do that, we need to use a new IRQ source= ID so > >> > the guest sees the logical OR of qemu requested state and extern= al > >> > device state. > >> > >> Given that yopu want to involve userspace anyway, why insist on ir= qfd > >> for this? =A0You can simply use KVM_IRQ_LINE_STATUS from qemu, no? > > > > Well, actually I'd like to have a way to bypass userspace, which th= e > > combination of an irqfd + eventfd w/ deassert does. Hmm but above you say > >> > 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. so what is the plan? > =A0I'm not quite sure > > I understand how KVM_IRQ_LINE_STATUS would work for this. =A0AIUI, = that > > effectively gives us a way to post an interrupt AND let us know whe= ther > > it was masked, coalesced, or delivered. =A0So I'd have to poll by p= osting > > a potentially spurious interrupt and if it was spurious unmask the > > physical device and wait for a real interrupt? =A0What am I missing= , > > because that seems barely functional? =A0Thanks, >=20 > Just to clarify, setting the interrupt from qemu isn't a problem. We > can do that just like any other device. The unique aspect is that we > need to know when the guest has issued an EOI so that we can unmask > the physical device interrupt and wait for it to fire again. This is > where I don't understand how KVM_IRQ_LINE_STATUS helps us. > The minimal support I mention above just requires informing userspace > about the EOI, then we can deassert and unmask from qemu. That means > we issue two more ioctl before we're enabled for the next interrupt. Exactly. > Rather than invent a new interface for a sub-optimal implementation, > fixing irqfd to support level triggered interrupts is potentially mor= e > useful and I think this implementation is not specific to device > assignment. BTW, what happens with vhost use of irqfd when the guest > runs out of MSI vectors? Could it use this interface for that? > Thanks, >=20 > Alex Sure. OTOH this never was a real issue - if it was we could teach Linux to share MSI interrupt. --=20 MST