[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1345051443.4683.425.camel@ul30vt.home>
Date: Wed, 15 Aug 2012 11:24:03 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: avi@...hat.com, gleb@...hat.com, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 6/6] kvm: Add de-assert option to KVM_IRQ_ACKFD
On Wed, 2012-08-15 at 17:11 +0300, Michael S. Tsirkin wrote:
> On Fri, Aug 10, 2012 at 04:37:56PM -0600, Alex Williamson wrote:
> > It's likely (vfio) that one of the reasons to watch for an IRQ ACK
> > is to de-assert and re-enable an interrupt. As the IRQ ACK notfier
> > is already watching a GSI for an IRQ source ID we can easily couple
> > these together.
> >
> > Signed-off-by: Alex Williamson <alex.williamson@...hat.com>
>
> This source id is required the only way to assert
> in the 1st place is with irqfd.
ioctl(fd, KVM_IRQ_ACKFD, kvm_irq_ackfd.{flags = 0, fd = eventfd, gsi = $GSI});
ioctl(fd, KVM_IRQ_LINE, kvm_irq_level.{irq = $GSI, level = 1);
/* eventfd notification */
ioctl(fd, KVM_IRQ_LINE, kvm_irq_level.{irq = $GSI, level = 0);
> So why is this an ackfd flag and not an irqfd flag?
> I am guessing because this way you do not need
> an extra ack notifier, but isn't this an internal
> optimization leaking out to userspace?
If irqfd were to setup it's own irq ack notifier for de-assert, we can
guarantee the ordering of de-assert vs eventfd trigger. So, whoever
does one, needs to do both. Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists