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: <49F5B2DA.5060207@novell.com>
Date:	Mon, 27 Apr 2009 09:27:54 -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:
> Gregory Haskins wrote:
>>>> This allows an eventfd to be registered as an irq source with a
>>>> guest.  Any
>>>> signaling operation on the eventfd (via userspace or kernel) will
>>>> inject
>>>> the registered GSI at the next available window.
>>>>
>>>>  
>>>> +struct kvm_irqfd {
>>>> +    __u32 fd;
>>>> +    __u32 gsi;
>>>> +};
>>>> +
>>>>         
>>> I think it's better to have ioctl create and return the fd.  This way
>>> we aren't tied to eventfd (though it makes a lot of sense to use it).
>>>     
>>
>> I dont mind either way, but I am not sure it buys us much as the one
>> driving the fd would need to understand if the interface is
>> eventfd-esque or something else anyway.  Let me know if you still want
>> to see this changed.
>>   
>
> Sure, the interface remains the same (write 8 bytes), but the
> implementation can change.  For example, we can implement it to work
> from interrupt context, once we hack the locking appropriately.

I was thinking more along the lines of eventfd_signal().  AIO and vbus
currently use this interface, as opposed to the more polymorhpic
f_ops->write().

>
>
>>>> +static void
>>>> +irqfd_inject(struct work_struct *work)
>>>> +{
>>>> +    struct _irqfd *irqfd = container_of(work, struct _irqfd, work);
>>>> +    struct kvm *kvm = irqfd->kvm;
>>>> +
>>>> +    mutex_lock(&kvm->lock);
>>>> +    kvm_set_irq(kvm, kvm->irqfd.src, irqfd->gsi, 1);
>>>>         
>>> Need to lower the irq too (though irqfd only supports edge triggered
>>> interrupts).
>>>
>>>     
>> Should I just do back-to-back 1+0 inside the same lock?
>>
>>   
>
> Yes.  Might be nice to add a kvm_toggle_irq(), but let's leave that
> until later.

Ok.

>
>
>  
>
>>> One day we'll have lockless injection and we'll want to drop this.  I
>>> guess if we create the fd ourselves we can make it work, but I don't
>>> see how we can do this with eventfd.
>>>
>>>     
>>
>> Hmm...this is a good point.  There probably is no way to use eventfd
>> "off the shelf" in a way that doesn't cause this callback to be in a
>> critical section.  Should we just worry about switching away from
>> eventfd when this occurs, or should I implement a custom anon-fd now?
>>   
>
> I'd just go with eventfd, and switch when it becomes relevant.  As
> long as the kernel allocates the fd, we're free to do as we like.

Sounds good.

-Greg



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