From: Jan Kiszka <jan.kiszka@web.de>
To: Gleb Natapov <gleb@redhat.com>
Cc: Blue Swirl <blauwirbel@gmail.com>,
qemu-devel@nongnu.org, Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
Date: Sun, 06 Jun 2010 09:39:04 +0200 [thread overview]
Message-ID: <4C0B5098.8030800@web.de> (raw)
In-Reply-To: <20100606071536.GA2337@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]
Gleb Natapov wrote:
> On Sat, Jun 05, 2010 at 02:04:01AM +0200, Jan Kiszka wrote:
>>> I'd like to also support EOI handling. When the guest clears the
>>> interrupt condtion, the EOI callback would be called. This could occur
>>> much later than the IRQ delivery time. I'm not sure if we need the
>>> result code in that case.
>>>
>>> If any intermediate device (IOAPIC?) needs to be informed about either
>>> delivery or EOI also, it could create a proxy message with its
>>> callbacks in place. But we need then a separate opaque field (in
>>> addition to payload) to store the original message.
>>>
>>> struct IRQMsg {
>>> DeviceState *src;
>>> void (*delivery_cb)(IRQMsg *msg, int result);
>>> void (*eoi_cb)(IRQMsg *msg, int result);
>>> void *src_opaque;
>>> void *payload;
>>> };
>> Extending the lifetime of IRQMsg objects beyond the delivery call stack
>> means qemu_malloc/free for every delivery. I think it takes a _very_
>> appealing reason to justify this. But so far I do not see any use case
>> for eio_cb at all.
>>
> I dislike use of eoi for reinfecting missing interrupts since
> it eliminates use of internal PIC/APIC queue of not yet delivered
> interrupts. PIC and APIC has internal queue that can handle two elements:
> one is delivered, but not yet acked interrupt in isr and another is
> pending interrupt in irr. Using eoi callback (or ack notifier as it's
> called inside kernel) interrupt will be considered coalesced even if irr
> is cleared, but no ack was received for previously delivered interrupt.
> But ack notifiers actually has another use: device assignment. There is
> a plan to move device assignment from kernel to userspace and for that
> ack notifiers will have to be extended to userspace too. If so we can
> use them to do irq decoalescing as well. I doubt they should be part
> of IRQMsg though. Why not do what kernel does: have globally registered
> notifier based on irqchip/pin.
I read this twice but I still don't get your plan. Do you like or
dislike using EIO for de-coalescing? And how should these notifiers work?
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2010-06-06 7:39 UTC|newest]
Thread overview: 122+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-24 20:13 [Qemu-devel] [RFT][PATCH 00/15] HPET cleanups, fixes, enhancements Jan Kiszka
2010-05-24 20:13 ` [Qemu-devel] [RFT][PATCH 01/15] hpet: Catch out-of-bounds timer access Jan Kiszka
2010-05-24 20:34 ` [Qemu-devel] " Juan Quintela
2010-05-24 20:36 ` Jan Kiszka
2010-05-24 20:50 ` Juan Quintela
2010-05-24 20:13 ` [Qemu-devel] [RFT][PATCH 02/15] hpet: Coding style cleanups and some refactorings Jan Kiszka
2010-05-24 20:37 ` [Qemu-devel] " Juan Quintela
2010-05-24 20:13 ` [Qemu-devel] [RFT][PATCH 03/15] hpet: Silence warning on write to running main counter Jan Kiszka
2010-05-24 20:13 ` [Qemu-devel] [RFT][PATCH 04/15] hpet: Move static timer field initialization Jan Kiszka
2010-05-24 20:13 ` [Qemu-devel] [RFT][PATCH 05/15] hpet: Convert to qdev Jan Kiszka
2010-05-25 9:37 ` Paul Brook
2010-05-25 10:14 ` Jan Kiszka
2010-05-24 20:13 ` [Qemu-devel] [RFT][PATCH 06/15] hpet: Start/stop timer when HPET_TN_ENABLE is modified Jan Kiszka
2010-05-24 20:13 ` [Qemu-devel] [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback Jan Kiszka
2010-05-25 6:07 ` Gleb Natapov
2010-05-25 6:31 ` Jan Kiszka
2010-05-25 6:40 ` Gleb Natapov
2010-05-25 6:54 ` Jan Kiszka
2010-05-25 19:09 ` [Qemu-devel] " Blue Swirl
2010-05-25 20:16 ` Anthony Liguori
2010-05-25 21:44 ` Jan Kiszka
2010-05-26 8:08 ` Gleb Natapov
2010-05-26 20:14 ` Blue Swirl
2010-05-27 5:42 ` Gleb Natapov
2010-05-26 19:55 ` Blue Swirl
2010-05-26 20:09 ` Jan Kiszka
2010-05-26 20:35 ` Blue Swirl
2010-05-26 22:35 ` Jan Kiszka
2010-05-26 23:26 ` Paul Brook
2010-05-27 17:56 ` Blue Swirl
2010-05-27 18:31 ` Jan Kiszka
2010-05-27 18:53 ` Blue Swirl
2010-05-27 19:08 ` Jan Kiszka
2010-05-27 19:19 ` Blue Swirl
2010-05-27 22:19 ` Jan Kiszka
2010-05-28 19:00 ` Blue Swirl
2010-05-30 12:00 ` Avi Kivity
2010-05-27 22:21 ` Paul Brook
2010-05-28 19:10 ` Blue Swirl
2010-05-27 22:21 ` Paul Brook
2010-05-27 6:13 ` Gleb Natapov
2010-05-27 18:37 ` Blue Swirl
2010-05-28 7:31 ` Gleb Natapov
2010-05-28 20:06 ` Blue Swirl
2010-05-28 20:47 ` Gleb Natapov
2010-05-29 7:58 ` Jan Kiszka
2010-05-29 9:35 ` Blue Swirl
2010-05-29 9:45 ` Jan Kiszka
2010-05-29 10:04 ` Blue Swirl
2010-05-29 10:16 ` Jan Kiszka
2010-05-29 10:26 ` Blue Swirl
2010-05-29 10:38 ` Jan Kiszka
2010-05-29 14:46 ` Gleb Natapov
2010-05-29 16:13 ` Blue Swirl
2010-05-29 16:37 ` Gleb Natapov
2010-05-29 21:21 ` Blue Swirl
2010-05-30 6:02 ` Gleb Natapov
2010-05-30 12:10 ` Blue Swirl
2010-05-30 12:24 ` Jan Kiszka
2010-05-30 12:58 ` Blue Swirl
2010-05-31 7:46 ` Jan Kiszka
2010-05-30 12:33 ` Gleb Natapov
2010-05-30 12:56 ` Blue Swirl
2010-05-30 13:49 ` Gleb Natapov
2010-05-30 16:54 ` Blue Swirl
2010-05-30 19:37 ` Blue Swirl
2010-05-30 20:07 ` Gleb Natapov
2010-05-30 20:21 ` Blue Swirl
2010-05-31 5:19 ` Gleb Natapov
2010-06-01 18:00 ` Blue Swirl
2010-06-01 18:30 ` Gleb Natapov
2010-06-02 19:05 ` Blue Swirl
2010-06-03 6:23 ` Jan Kiszka
2010-06-03 6:34 ` Gleb Natapov
2010-06-03 6:59 ` Jan Kiszka
2010-06-03 7:03 ` Gleb Natapov
2010-06-03 7:06 ` Gleb Natapov
2010-06-04 19:05 ` Blue Swirl
2010-06-05 0:04 ` Jan Kiszka
2010-06-05 7:20 ` Blue Swirl
2010-06-05 8:27 ` Jan Kiszka
2010-06-05 9:23 ` Blue Swirl
2010-06-05 12:14 ` Jan Kiszka
2010-06-06 7:15 ` Gleb Natapov
2010-06-06 7:39 ` Jan Kiszka [this message]
2010-06-06 7:49 ` Gleb Natapov
2010-06-06 8:07 ` Jan Kiszka
2010-06-06 9:23 ` Gleb Natapov
2010-06-06 10:10 ` Jan Kiszka
2010-06-06 10:27 ` Gleb Natapov
2010-06-06 7:39 ` Blue Swirl
2010-06-06 8:07 ` Gleb Natapov
2010-05-30 13:22 ` Blue Swirl
2010-05-29 9:15 ` Blue Swirl
2010-05-29 9:36 ` Jan Kiszka
2010-05-29 14:38 ` Gleb Natapov
2010-05-29 16:03 ` Blue Swirl
2010-05-29 16:32 ` Gleb Natapov
2010-05-29 20:52 ` Blue Swirl
2010-05-30 5:41 ` Gleb Natapov
2010-05-30 11:41 ` Blue Swirl
2010-05-30 11:52 ` Gleb Natapov
2010-05-30 12:05 ` Avi Kivity
2010-05-27 5:58 ` Gleb Natapov
2010-05-26 19:49 ` Blue Swirl
2010-05-24 20:13 ` [Qemu-devel] [RFT][PATCH 08/15] x86: Refactor RTC IRQ coalescing workaround Jan Kiszka
2010-05-24 20:13 ` [Qemu-devel] [RFT][PATCH 09/15] hpet/rtc: Rework RTC IRQ replacement by HPET Jan Kiszka
2010-05-25 9:29 ` Paul Brook
2010-05-25 10:23 ` Jan Kiszka
2010-05-25 11:05 ` Paul Brook
2010-05-25 11:19 ` Jan Kiszka
2010-05-25 11:23 ` Paul Brook
2010-05-25 11:26 ` Jan Kiszka
2010-05-25 12:03 ` Paul Brook
2010-05-25 12:39 ` Jan Kiszka
2010-05-24 20:13 ` [Qemu-devel] [RFT][PATCH 10/15] hpet: Drop static state Jan Kiszka
2010-05-24 20:13 ` [Qemu-devel] [RFT][PATCH 11/15] hpet: Add support for level-triggered interrupts Jan Kiszka
2010-05-24 20:13 ` [Qemu-devel] [RFT][PATCH 12/15] vmstate: Add VMSTATE_STRUCT_VARRAY_UINT8 Jan Kiszka
2010-05-24 20:13 ` [Qemu-devel] [RFT][PATCH 13/15] hpet: Make number of timers configurable Jan Kiszka
2010-05-24 20:13 ` [Qemu-devel] [RFT][PATCH 14/15] hpet: Add MSI support Jan Kiszka
2010-05-24 20:13 ` [Qemu-devel] [RFT][PATCH 15/15] monitor/QMP: Drop info hpet / query-hpet Jan Kiszka
2010-05-24 22:16 ` [Qemu-devel] [RFT][PATCH 00/15] HPET cleanups, fixes, enhancements Anthony Liguori
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=4C0B5098.8030800@web.de \
--to=jan.kiszka@web.de \
--cc=blauwirbel@gmail.com \
--cc=gleb@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).