linux-kernel - Re: [KVM PATCH v2 2/2] kvm: add support for irqfd via eventfd-notification interface

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: <49F6EACA.3050808@novell.com>
Date:	Tue, 28 Apr 2009 07:38:50 -0400
From:	Gregory Haskins <ghaskins@...ell.com>
To:	Avi Kivity <avi@...hat.com>
CC:	kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	davidel@...ilserver.org
Subject: Re: [KVM PATCH v2 2/2] kvm: add support for irqfd via	eventfd-notification
 interface

Avi Kivity wrote:
> Avi Kivity wrote:
>>>
>>> So what is your proposal for such interface?
>>>
>>>   
>>
>> ->write().
>>
>
> Alternatively, a new fileop ->signal_event(), which would map to
> eventfd_signal() or irqfd_signal().  This would be defined to work in
> irq contexts.  It may also be useful for uio interrupts.
>
Hmm...I'm not crazy about either of those.  write() has obvious
limitations both from a interrupt execution context, as well as the
awkwardness of dealing with creating+passing a viable "userspace"
pointer from kernel code.  On the other hand, a new fileop doesn't quite
seem appropriate either since it doesn't apply to the overall fileop
abstraction very well.

We could potentially have a separate vtable interface just for
event-type fds, and make eventfd and irqfd the first implementations. 
But I am not sure it is worth it.  What I suggest is that we work within
the existing eventfd interface.  It was designed specifically to signal
events, after all.

If at some point in the future we need to ensure that the callbacks are
not invoked from a preempt-off/irq-off critical section, we can revist
the eventfd internals at that time.  Note that since we would like to
support signaling from interrupt context anyway, trying to get rid of
the wqh critical section that we have today may be a fools errand (*). 
Instead, we should probably focus on making the injection path support
non-preemptible contexts, as this will have the biggest benefits and
gains in the long run.

Thoughts?
-Greg

(*) The biggest benefit is that you can do tricks like
                                  "if (preemptible()) do_it_now(); else
do_it_later();"

Download attachment "signature.asc" of type "application/pgp-signature" (267 bytes)