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: <20120627095814.GJ17507@redhat.com>
Date:	Wed, 27 Jun 2012 12:58:14 +0300
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Alex Williamson <alex.williamson@...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 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.

> 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.

> 
> I don't address whether injecting an edge irqfd really needs an assert
> followed by de-assert (I don't know).  This new interface really
> unties itself from caring.  We might be able to consolidate inject
> functions at some future point, but it doesn't change how we'd name
> flags as it did in the previous version.  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/