linux-kernel - Re: [PATCH v2 0/6] kvm: level triggered irqfd support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1340807620.1207.210.camel@bling.home>
Date:	Wed, 27 Jun 2012 08:33:40 -0600
From:	Alex Williamson <alex.williamson@...hat.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	avi@...hat.com, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	jan.kiszka@...mens.com
Subject: Re: [PATCH v2 0/6] kvm: level triggered irqfd support

On Wed, 2012-06-27 at 12:58 +0300, Michael S. Tsirkin wrote:
> On Tue, Jun 26, 2012 at 11:08:52PM -0600, Alex Williamson wrote:
> > Ok, let's see how this flies.  I actually quite like this, so be
> > gentle tearing it apart ;)
> > 
> > I just couldn't bring myself to contort KVM_IRQFD into something
> > that either sets up an irqfd or specifies a nearly unrelated EOI
> > eventfd.  The solution I've come up with, that also avoids exposing
> > irq_source_ids to userspace, is to work through the irqfd.  If we
> > setup a level irqfd, we can optionally associate an eoifd with
> > the same irq_source_id, by passing the irqfd.  To do this, we just
> > need to create a new reference counted object for the source ID
> > so we don't run into problems ordering release.  This means we
> > end up with a KVM_EOIFD ioctl that has both general usefulness and
> > can still tie into an irqfd.
> 
> I like this API.

Yay!  I'll work on the bugs you've spotted.

> > In patch 6/6 I also include an alternate de-assert mechanism via an
> > irqfd with the opposite polarity.  I don't currently use this, but
> > it's pretty trivial and at least available in archives now.
> 
> The nasty bit about that is that if you assert twice then
> deassert once it's not clear what should happen.
> But yea, it does not hurt to put them in the archives.

It's no different that KVM_IRQ_LINE in that sense.  It's not an
accumulator, it's a set state.  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/