On Sun, Jun 13, 2010 at 05:34:24PM +0100, Paul Brook wrote:
> > TBH I preferred the original system whereby the source can query the state
> > of the sink (i.e "are you ignoring this line?"). Note that conceptually
> > this should be *querying* state, not responding to an event.
>
> People are st
> >> For the memory access case, in practice the interface could be
> >> sysbus_memory_rw(DeviceState *parent, target_phys_addr_t addr,
> >> target_phys_addr_t size)
> >
> > Why "parent"?
>
> Parent device or bus host bridge device. Alternatively there could be
> a bus handle.
A device has no wa
On Sun, Jun 13, 2010 at 6:39 PM, Paul Brook wrote:
>> On Sun, Jun 13, 2010 at 3:49 PM, Paul Brook wrote:
>> >> 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 in
> On Sun, Jun 13, 2010 at 3:49 PM, Paul Brook wrote:
> >> 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
On Sun, Jun 13, 2010 at 3:49 PM, Paul Brook wrote:
>> 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 cop
On Sun, Jun 13, 2010 at 4:34 PM, Paul Brook wrote:
>> TBH I preferred the original system whereby the source can query the state
>> of the sink (i.e "are you ignoring this line?"). Note that conceptually
>> this should be *querying* state, not responding to an event.
>
> People are still pushing
> TBH I preferred the original system whereby the source can query the state
> of the sink (i.e "are you ignoring this line?"). Note that conceptually
> this should be *querying* state, not responding to an event.
People are still pushing qemu_irq as an message passing interface, so I'm
going to
> 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)
On Sat, Jun 12, 2010 at 8:32 PM, Blue Swirl wrote:
> On Sat, Jun 12, 2010 at 7:33 PM, Blue Swirl wrote:
>> On Sat, Jun 12, 2010 at 3:58 PM, Paul Brook 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/IOA
On Sat, Jun 12, 2010 at 7:33 PM, Blue Swirl wrote:
> On Sat, Jun 12, 2010 at 3:58 PM, Paul Brook 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 Sign
> > [*] 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
> >
On Sat, Jun 12, 2010 at 3:58 PM, Paul Brook 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
> 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
On Sat, Jun 12, 2010 at 2:15 PM, Paul Brook wrote:
>> On Sat, Jun 12, 2010 at 12:21 PM, Paul Brook wrote:
>> >> This patch allows to optionally attach a message to an IRQ event. The
>> >> message can contain a payload reference and a callback that the IRQ
>> >> handler may invoke to report the de
> On Sat, Jun 12, 2010 at 12:21 PM, Paul Brook wrote:
> >> This patch allows to optionally attach a message to an IRQ event. The
> >> message can contain a payload reference and a callback that the IRQ
> >> handler may invoke to report the delivery result. The former can be used
> >> to model mess
On Sat, Jun 12, 2010 at 12:21 PM, Paul Brook wrote:
>> This patch allows to optionally attach a message to an IRQ event. The
>> message can contain a payload reference and a callback that the IRQ
>> handler may invoke to report the delivery result. The former can be used
>> to model message signal
Paul Brook wrote:
>> This patch allows to optionally attach a message to an IRQ event. The
>> message can contain a payload reference and a callback that the IRQ
>> handler may invoke to report the delivery result. The former can be used
>> to model message signaling interrupts, the latter to clean
> This patch allows to optionally attach a message to an IRQ event. The
> message can contain a payload reference and a callback that the IRQ
> handler may invoke to report the delivery result. The former can be used
> to model message signaling interrupts, the latter to cleanly implement
> IRQ de-
From: Jan Kiszka
This patch allows to optionally attach a message to an IRQ event. The
message can contain a payload reference and a callback that the IRQ
handler may invoke to report the delivery result. The former can be used
to model message signaling interrupts, the latter to cleanly implemen
19 matches
Mail list logo
