From: Anthony Liguori <aliguori@us.ibm.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Juha Riihimäki" <juha.riihimaki@nokia.com>,
"patches@linaro.org" <patches@linaro.org>,
"Jan Kiszka" <jan.kiszka@siemens.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Markus Armbruster" <armbru@redhat.com>,
"Paul Brook" <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices
Date: Fri, 10 Jun 2011 09:07:57 -0500 [thread overview]
Message-ID: <4DF2253D.2090300@us.ibm.com> (raw)
In-Reply-To: <BANLkTi=L-FsG1jg_nGxfz_6Xzm+OjD=9ZA@mail.gmail.com>
On 06/10/2011 08:10 AM, Peter Maydell wrote:
> On 10 June 2011 13:51, Anthony Liguori<aliguori@us.ibm.com> wrote:
>> On 06/10/2011 03:13 AM, Markus Armbruster wrote:
>>>
>>> Jan Kiszka<jan.kiszka@siemens.com> writes:
>>>>
>>>> Resource management, e.g. IRQs. That will be useful for other types of
>>>> buses as well.
>>>
>>> A device should be able to say "I need to be connected to an IRQ line".
>>> Feels generic to me.
>>
>> More specifically, a device has input IRQs. A device has no idea what
>> number the IRQ is tied to.
>>
>> Devices may also have output IRQs. At the qdev layer, we should be able to
>> connect an arbitrary output IRQ to an arbitrary input IRQ.
>
> Actually, devices have input and output I/O signals (GPIOs, if you like).
Yes, I prefer the term Pin but since the discussion was using IRQs, I
didn't want to rock the boat ;-)
> A subset of these are IRQs. We already have some APIs in QEMU which
> claim to be dealing with 'irq's but actually are just for wiring
> up generic signals; I'd rather we didn't proliferate that terminology
> confusion if possible. (And a single GPIO wire is just one kind of
> thing you might want to link between two devices, obviously. MMIO is
> another.)
Forget about MMIO. From a device perspective, MMIO is an extremely high
level concept. MMIO almost always involves some higher level interface
(like PCI, ISA, etc.).
That's really the interface that you want to model. Sysbus ends up
being treated as a generic bus in-lieu of implementing machine specific
buses (probably because they're proprietary and undocumented). That's
sort of okay but we should treat that not as the parent bus of
everything but as a generic bus type.
>> So the crux of the problem is that:
>>
>> -device isa-serial,id=serial,irq=3
>>
>> Is very wrong. It ought to look something more like
>>
>> -device piix3,id=piix3 -device isa-serial,id=serial,irq=piix3.irq[3]
>
> This makes the wiring of this signal look like a property of the
> isa-serial device, which is a bit odd, since it's just as much
> a property of the piix3. Actually it's neither, it's a property
> of the machine model, and you might actually want a syntax a bit
> more like:
Think of it like a graph with directed paths. The property is the end
point of the connection.
But the key point is: the connections of the graph *IS* the machine model.
>
> piix3 = piix3(property=value, property=value...);
> serial = isa-serial(property=value...);
> connect(serial.irq, piix3.irq[3]);
You can use a different verb but essentially, it's still:
serial.irq OPERATOR piix3.irq[3]
Picking a direction and using assignment is convenient syntactically.
Regards,
Anthony Liguori
>
> (in some mythical stitching language, which I think makes much
> more sense than command line switches anyway.)
>
> -- PMM
next prev parent reply other threads:[~2011-06-10 14:08 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-08 11:33 [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices Peter Maydell
2011-06-08 11:33 ` [Qemu-devel] [PATCH RFC 1/3] sysbus: Add support for resizing and unmapping MMIOs Peter Maydell
2011-06-08 11:33 ` [Qemu-devel] [PATCH RFC 2/3] sysbus: Allow sysbus MMIO passthrough Peter Maydell
2011-06-08 11:33 ` [Qemu-devel] [PATCH RFC 3/3] sysbus: Allow passthrough of single IRQ Peter Maydell
2011-06-08 12:29 ` [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices Jan Kiszka
2011-06-09 16:40 ` Markus Armbruster
2011-06-09 17:03 ` Jan Kiszka
2011-06-10 8:13 ` Markus Armbruster
2011-06-10 12:51 ` Anthony Liguori
2011-06-10 13:10 ` Peter Maydell
2011-06-10 13:43 ` Jan Kiszka
2011-06-10 13:50 ` Peter Maydell
2011-06-10 14:22 ` Markus Armbruster
2011-06-10 14:45 ` Anthony Liguori
2011-06-10 14:34 ` Anthony Liguori
2011-06-10 14:12 ` Anthony Liguori
2011-06-10 14:18 ` Jan Kiszka
2011-06-10 14:31 ` Anthony Liguori
2011-06-10 14:07 ` Anthony Liguori [this message]
2011-06-10 14:59 ` Markus Armbruster
2011-06-10 15:43 ` Anthony Liguori
2011-06-12 17:12 ` Avi Kivity
2011-06-12 19:21 ` Anthony Liguori
2011-06-13 8:05 ` Avi Kivity
2011-06-13 17:53 ` Anthony Liguori
2011-06-13 20:59 ` Blue Swirl
2011-06-14 13:21 ` Anthony Liguori
2011-06-15 18:56 ` Blue Swirl
2011-06-15 20:00 ` Anthony Liguori
2011-06-15 20:20 ` Blue Swirl
2011-06-20 15:23 ` Paul Brook
2011-06-20 21:32 ` Blue Swirl
2011-06-21 8:16 ` Avi Kivity
2011-06-27 2:26 ` Paul Brook
2011-06-13 9:57 ` Gleb Natapov
2011-06-10 16:28 ` Andreas Färber
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=4DF2253D.2090300@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=armbru@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=juha.riihimaki@nokia.com \
--cc=patches@linaro.org \
--cc=paul@codesourcery.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.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 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).