qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Blue Swirl <blauwirbel@gmail.com>
To: Paul Brook <paul@codesourcery.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	Jan Kiszka <jan.kiszka@web.de>,
	qemu-devel@nongnu.org, Gleb Natapov <gleb@redhat.com>,
	Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs
Date: Sat, 12 Jun 2010 20:32:12 +0000	[thread overview]
Message-ID: <AANLkTim9u85rRcRXKn0DS-sZEoJSIOa4WJq4Xlo2eaLF@mail.gmail.com> (raw)
In-Reply-To: <AANLkTilhCLANjs6dTH3gu_M_l-haeU2jWr7Jxy1igJtZ@mail.gmail.com>

On Sat, Jun 12, 2010 at 7:33 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> On Sat, Jun 12, 2010 at 3:58 PM, Paul Brook <paul@codesourcery.com> wrote:
>>> I think message passing interrupts
>>> are only used in bus based systems, like PCI or UPA/JBUS etc. I don't
>>> know how LAPIC/IOAPIC bus works, it could be similar.
>>
>> PCI Message Signalled Interrupts use a regular data write, and we model it
>> exactly that way. Under normal circumstances you program the device to write
>> to memory mapped APIC control registers, but there's no real reason why you
>> couldn't write to RAM.
>>
>> LAPIC/IOAPIC have their own bus. On some hardware this is multiplexed over the
>> main system bus, but logically it is a separate interconnect.
>>
>> The fact that these a bus based systems suggests against using qemu_irq, which
>> is an inherently point-point system.
>>
>>> > How is a
>>> > receiver meant to know for format of the message being delivered, and who
>>> > it's intended for?
>>>
>>> This depends on the architecture. On Sparc64 the message is specified
>>> by the guest or OF.
>>>...
>>> In real HW (MSI or Sparc64 mondo interrupts) a bus delivers the
>>> message. But our buses only handle address and data lines.
>>
>> IIUC you're trying to use qemu_irq as a generic interconnect between devices.
>> I think that's going to cause more problems than it solves.  If a bus has
>> additional message passing capabilities then this can be part of the bus
>> interface.
>>
>> If two devices need a private communication channel then we probably want some
>> implementation agnostic way of defining this link.  Connecting LAPIC to IOAPIC
>> is a potential example of this. However this needs to be done in a type-safe
>> manner.  DMA channels may be another potential use of this linking. We'd want
>> to avoid connecting a DMA channel to an APIC.
>>
>> [*] A simple unidirectional dma request line is suitable for qmu_irq. A DMA
>> system that transfers data outside of memory read/write transactions is not.
>> e.g. ISA effectively defines a regular memory bus plus 8 bidirectional data
>> streams (aka DMA channels). These are multiplexed over the same physical pins,
>> but logically distinct. The DMA channels could either be bundled up into the
>> ISA bus interface, or modelled as links between devices and the DMA
>> controller.
>
> Very very interesting. There's some out of band data related to DMA
> (bus errors, IOMMU faults, ISA DREQ) which hasn't been covered in
> previous Generic DMA proposals. Maybe all we need is a generic side
> band link, which would be usable for point to point (qemu_irq,
> coalescing, messages) and bus channels?

I think we could solve all problems (well, maybe not world peace, yet)
by switching to message based system for all of DMA and IRQs.

Each device would have a message input port and way to output messages.

Examples:

Zero copy memory access from device D1 to D2 to host memory (D3) with
access broken to page length units and errors occurring on the last
byte:
D1 send_msg(ID, MSG_MEM_WRITE, DMA address, length) -> D2
D2 send_msg(ID, MSG_MEM_WRITE, DMA address2, length) -> D3
D3 send_replymsg(ID, MSG_MEM_PTR, host address, 4096) -> D2
D2 send_replymsg(ID, MSG_MEM_PTR, host address, 4096) -> D1
D3 send_replymsg(ID, MSG_MEM_PTR, host address, length - 4096 - 1) -> D2
D2 send_replymsg(ID, MSG_MEM_PTR, host address, length - 4096 - 1) -> D1
D3 send_replymsg(ID, MSG_MEM_ERROR, DMA address2 + length - 1, 1, status) -> D2
D2 send_replymsg(ID, MSG_MEM_ERROR, DMA address + length - 1, 1, status) -> D1

IRQ delivery chain D1->D2->D3 with coalescing, messages, delivery
reporting and EOI:
D1 send_msg(ID, MSG_IRQ_RAISE, payload) -> D2
D2 send_msg(ID, MSG_IRQ_RAISE, payload) -> D3
D3 send_replymsg(ID, MSG_IRQ_STATUS, MI_COALESCED) -> D2
D2 send_replymsg(ID, MSG_IRQ_STATUS, MI_COALESCED) -> D1
D3 send_replymsg(ID, MSG_IRQ_STATUS, MI_DELIVERED) -> D2
D2 send_replymsg(ID, MSG_IRQ_STATUS, MI_DELIVERED) -> D1
D3 send_replymsg(ID, MSG_IRQ_STATUS, MI_EOI) -> D2
D2 send_replymsg(ID, MSG_IRQ_STATUS, MI_EOI) -> D1

What else do we want? :-)

  parent reply	other threads:[~2010-06-12 20:32 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-06  8:10 [Qemu-devel] [PATCH 00/16] HPET cleanups, fixes, enhancements Jan Kiszka
2010-06-06  8:10 ` [Qemu-devel] [PATCH 01/16] hpet: Catch out-of-bounds timer access Jan Kiszka
2010-06-06  8:10 ` [Qemu-devel] [PATCH 02/16] hpet: Coding style cleanups and some refactorings Jan Kiszka
2010-06-06  8:10 ` [Qemu-devel] [PATCH 03/16] hpet: Silence warning on write to running main counter Jan Kiszka
2010-06-06  8:10 ` [Qemu-devel] [PATCH 04/16] hpet: Move static timer field initialization Jan Kiszka
2010-06-06  8:10 ` [Qemu-devel] [PATCH 05/16] hpet: Convert to qdev Jan Kiszka
2010-06-06  8:10 ` [Qemu-devel] [PATCH 06/16] hpet: Start/stop timer when HPET_TN_ENABLE is modified Jan Kiszka
2010-06-06  8:10 ` [Qemu-devel] [PATCH 07/16] monitor/QMP: Drop info hpet / query-hpet Jan Kiszka
2010-06-06  8:10 ` [Qemu-devel] [PATCH 08/16] Pass IRQ object on handler invocation Jan Kiszka
2010-06-12 10:31   ` [Qemu-devel] [PATCH v3 " Jan Kiszka
2010-06-06  8:10 ` [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs Jan Kiszka
2010-06-12 12:21   ` Paul Brook
2010-06-12 12:32     ` Jan Kiszka
2010-06-12 13:44     ` Blue Swirl
2010-06-12 14:15       ` Paul Brook
2010-06-12 14:35         ` Blue Swirl
2010-06-12 15:58           ` Paul Brook
2010-06-12 19:33             ` Blue Swirl
2010-06-12 20:15               ` Paul Brook
2010-06-12 20:32               ` Blue Swirl [this message]
2010-06-13  6:47                 ` Blue Swirl
2010-06-13 15:49                 ` Paul Brook
2010-06-13 18:17                   ` Blue Swirl
2010-06-13 18:39                     ` Paul Brook
2010-06-13 18:54                       ` Blue Swirl
2010-06-13 19:38                         ` Paul Brook
2010-06-13 16:34         ` Paul Brook
2010-06-13 18:04           ` Blue Swirl
2010-06-14  5:40           ` Gleb Natapov
2010-06-06  8:10 ` [Qemu-devel] [PATCH 10/16] x86: Refactor RTC IRQ coalescing workaround Jan Kiszka
2010-06-06  8:49   ` [Qemu-devel] " Blue Swirl
2010-06-06  9:06     ` Jan Kiszka
2010-06-06  8:11 ` [Qemu-devel] [PATCH 11/16] hpet/rtc: Rework RTC IRQ replacement by HPET Jan Kiszka
2010-06-06  8:53   ` [Qemu-devel] " Blue Swirl
2010-06-06  9:09     ` Jan Kiszka
2010-06-06  8:11 ` [Qemu-devel] [PATCH 12/16] hpet: Drop static state Jan Kiszka
2010-06-06  8:11 ` [Qemu-devel] [PATCH 13/16] hpet: Add support for level-triggered interrupts Jan Kiszka
2010-06-06  8:11 ` [Qemu-devel] [PATCH 14/16] vmstate: Add VMSTATE_STRUCT_VARRAY_UINT8 Jan Kiszka
2010-06-06  8:11 ` [Qemu-devel] [PATCH 15/16] hpet: Make number of timers configurable Jan Kiszka
2010-06-06  8:11 ` [Qemu-devel] [PATCH 16/16] hpet: Add MSI support Jan Kiszka
2010-06-11 21:31   ` Paul Brook
2010-06-12 10:23     ` [Qemu-devel] [PATCH v3 " Jan Kiszka
2010-06-06  8:56 ` [Qemu-devel] Re: [PATCH 00/16] HPET cleanups, fixes, enhancements Blue Swirl
2010-06-06  9:12   ` Jan Kiszka

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=AANLkTim9u85rRcRXKn0DS-sZEoJSIOa4WJq4Xlo2eaLF@mail.gmail.com \
    --to=blauwirbel@gmail.com \
    --cc=gleb@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=jan.kiszka@web.de \
    --cc=paul@codesourcery.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).