From: Markus Armbruster <armbru@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Marcel Apfelbaum <marcel@redhat.com>,
Laszlo Ersek <lersek@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] q35 and sysbus devices
Date: Fri, 24 Mar 2017 18:59:31 +0100 [thread overview]
Message-ID: <877f3emu7w.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <CAFEAcA_V3w6-WELX_M-jW1M=2TV7-wmEWa-c40ZmXLywC=+=Cg@mail.gmail.com> (Peter Maydell's message of "Fri, 24 Mar 2017 17:08:56 +0000")
Peter Maydell <peter.maydell@linaro.org> writes:
> On 24 March 2017 at 16:58, Markus Armbruster <armbru@redhat.com> wrote:
>> "Sysbus" isn't a bus. In qdev's original design, every device had to
>> plug into a bus, period. The ones that really didn't were made to plug
>> into "sysbus".
>>
>> Pretty much the only thing "sysbus" devices had in common was that they
>> couldn't be used with device_add and device_del.
>
> This isn't really true. Sysbus devices support having MMIO regions
> and IRQ lines and GPIO lines. If you need those you're a
> sysbus device; otherwise you can probably just be a plain old Device.
Well, "device has MMIO regions, IRQ lines and GPIO lines" is about as
"device contains virtual silicon". What would a device without any of
these *do*?
Devices plugging into a bus have to expose their MMIO regions, IRQ
lines, etc. in a certain way dictated by the bus. In return, you don't
have to wire up each resource manually, you simply plug into the bus and
are done. That's what makes a bus a bus for me.
"Sysbus" does nothing of the sort.
>> We fixed the design to permit bus-less devices, but we didn't get rid of
>> "sysbus".
>
> Call it what you want, but we should have some common code support
> for "I want to have MMIOs and IRQs and GPIO lines".
Of course.
> You could
> argue for moving all that into Device I suppose.
Yup.
>> We got a "platform bus", which is really not the same as "sysbus", but
>> we shoehorned it into "sysbus" anyway.
>
> I agree 'platform bus' is a mess, and I'd rather it didn't exist.
> Unfortunately people really really want to be able to do device
> pass through of random memory-mapped devices :-(
The "platform" bus adds certain constraints over "sysbus", precisely to
make these uses possible. And that's precisely why it should be its own
thing instead of complicating "sysbus".
next prev parent reply other threads:[~2017-03-24 17:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-22 20:31 [Qemu-devel] q35 and sysbus devices Eduardo Habkost
2017-03-22 20:46 ` Laszlo Ersek
2017-03-24 10:49 ` Marcel Apfelbaum
2017-03-24 13:48 ` Eduardo Habkost
2017-03-24 14:13 ` Peter Maydell
2017-03-24 19:04 ` Eduardo Habkost
2017-03-24 16:58 ` Markus Armbruster
2017-03-24 17:08 ` Peter Maydell
2017-03-24 17:59 ` Markus Armbruster [this message]
2017-03-24 18:10 ` Peter Maydell
2017-03-27 8:00 ` Thomas Huth
2017-03-24 19:23 ` Eduardo Habkost
2017-03-27 8:44 ` Cornelia Huck
2017-03-27 9:00 ` Peter Maydell
2017-03-27 16:11 ` Eduardo Habkost
2017-03-24 11:41 ` Thomas Huth
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=877f3emu7w.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=ehabkost@redhat.com \
--cc=lersek@redhat.com \
--cc=marcel@redhat.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 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.