From: Gregory Haskins <gregory.haskins@gmail.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Gregory Haskins <ghaskins@novell.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
alacrityvm-devel@lists.sourceforge.net
Subject: Re: [KVM PATCH 1/2] KVM: Directly inject interrupts via irqfd
Date: Wed, 21 Oct 2009 11:42:21 -0400 [thread overview]
Message-ID: <4ADF2BDD.40706@gmail.com> (raw)
In-Reply-To: <20091021153640.GS29477@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]
Gleb Natapov wrote:
> On Wed, Oct 21, 2009 at 11:34:51AM -0400, Gregory Haskins wrote:
>> Gleb Natapov wrote:
>>> On Wed, Oct 21, 2009 at 10:34:53AM -0400, Gregory Haskins wrote:
>>>> IRQFD currently uses a deferred workqueue item to execute the injection
>>>> operation. It was originally designed this way because kvm_set_irq()
>>>> required the caller to hold the irq_lock mutex, and the eventfd callback
>>>> is invoked from within a non-preemptible critical section.
>>>>
>>>> With the advent of lockless injection support in kvm_set_irq, the deferment
>>>> mechanism is no longer technically needed. Since context switching to the
>>>> workqueue is a source of interrupt latency, lets switch to a direct
>>>> method.
>>>>
>>> kvm_set_irq is fully lockless only in MSI case. IOAPIC/PIC has mutexes.
>> Right, but irqfd by design only works with MSI (or MSI like edge
>> triggers) anyway. Legacy-type injections follow a different path.
>>
> Ah, If this the case and it will stay that way then the change looks OK
> to me.
I believe Avi, Michael, et. al. were in agreement with me on that design
choice. I believe the reason is that there is no good way to do EOI/ACK
feedback within the constraints of an eventfd pipe which would be
required for the legacy pin-type interrupts. Therefore, we won't even
bother trying. High-performance subsystems will use irqfd/msi, and
legacy emulation can use the existing injection code (which includes the
necessary feedback for ack/eoi).
To that point, perhaps it should be better documented. If we need a v2,
I will add a comment.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
next prev parent reply other threads:[~2009-10-21 15:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-21 14:34 [KVM PATCH 0/2] irqfd enhancements Gregory Haskins
2009-10-21 14:34 ` [KVM PATCH 1/2] KVM: Directly inject interrupts via irqfd Gregory Haskins
2009-10-21 15:26 ` Gleb Natapov
2009-10-21 15:34 ` Gregory Haskins
2009-10-21 15:36 ` Gleb Natapov
2009-10-21 15:42 ` Gregory Haskins [this message]
2009-10-22 15:07 ` Avi Kivity
2009-10-22 15:14 ` Gregory Haskins
2009-10-22 15:19 ` Avi Kivity
2009-10-22 15:33 ` Gregory Haskins
2009-10-21 14:34 ` [KVM PATCH 2/2] KVM: Remove unecessary irqfd-cleanup-wq Gregory Haskins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ADF2BDD.40706@gmail.com \
--to=gregory.haskins@gmail.com \
--cc=alacrityvm-devel@lists.sourceforge.net \
--cc=ghaskins@novell.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.