From: Paolo Bonzini <pbonzini@redhat.com>
To: Alexander Graf <agraf@suse.de>,
Eric Auger <eric.auger@linaro.org>,
eric.auger@st.com, christoffer.dall@linaro.org,
qemu-devel@nongnu.org, a.rigo@virtualopensystems.com,
kim.phillips@freescale.com, marc.zyngier@arm.com,
manish.jaggi@caviumnetworks.com, joel.schopp@amd.com,
peter.maydell@linaro.org, afaerber@suse.de
Cc: patches@linaro.org, will.deacon@arm.com,
stuart.yoder@freescale.com, Bharat.Bhushan@freescale.com,
alex.williamson@redhat.com, a.motakis@virtualopensystems.com,
kvmarm@lists.cs.columbia.edu
Subject: Re: [Qemu-devel] [PATCH v3 1/6] hw/misc/dyn_sysbus_binding: helpers for sysbus device dynamic binding
Date: Wed, 10 Sep 2014 12:05:12 +0200 [thread overview]
Message-ID: <54102258.4040503@redhat.com> (raw)
In-Reply-To: <54102068.6000807@suse.de>
Il 10/09/2014 11:56, Alexander Graf ha scritto:
>
>
> On 10.09.14 11:43, Paolo Bonzini wrote:
>> Il 10/09/2014 11:31, Alexander Graf ha scritto:
>>>>> Yeah, please do the registration in sysbus.c, not in virt.c. There is
>>>>> no reason to make the platform_bus_init_notify+DynSysbusNotifier
>>>>> interface public. The code in sysbus.c can fill in the fields.
>>> Sysbus != Platform bus. Sysbus is an in-QEMU representation of a
>>> pseudo-bus that we put all devices onto that we consider unsorted.
>>>
>>> Platform bus is a machine representation of an actual bus that devices
>>> are attached to. These devices usually are sysbus devices.
>>
>> Is there any difference between the two?
>>
>> Take a machine that has two chips, a SoC that does everything except
>> USB, and a USB controller chip.
>>
>> Strictly speaking the USB controller chip would be on a "platform bus",
>> but we would likely put it on sysbus.
>>
>> Why should it matter whether the devices are static or dynamic, for the
>> sake of calling something the "system" or the "platform" bus? I would
>> say that QEMU calls "sysbus" the platform bus.
>>
>> Some devices (e.g. the local APIC in x86, or the in-core timers and GIC
>> in ARM) should probably not be in sysbus at all, and should attach
>> directly to the CPU address space. But that is a quirk in the modeling
>> of those devices, it shouldn't mean that sysbus is not a "platform" bus.
>
> On e500 for example, we have a predefined CCSR region. That is a machine
> defined "platform bus". The offsets inside that region are strictly
> defined by the spec.
>
> Now take the serial ports. We have space for 2 serial ports inside of
> that CCSR region. We can spawn these 2 ports in the machine file based
> on -serial, but if you want to spawn them with -device, how do you tell
> the machine whether they should go into the "big bucket platform bus" or
> the "CCSR platform bus"?
Two possibilities:
1) you would use two instances of sysbus (one default, one created by
the board) and specify ",bus=ccsr" on the command line when you want to
add the device to the CCSR region.
The two would work exactly the same way, only with different algorithms
for resource allocation.
2) similar to ISA, you would create a new ccsr-bus device and a new
ccsr-serial device, and use -device ccsr-serial,index=[0|1],chardev=foo
to specify which of the two serial ports this is for. Most of the fdt
magic could be shared by the sysbus and CCSR cases.
I think I prefer (2)...
Paolo
> In fact, thinking about this a bit more, maybe we should just have an
> actual bus structure. Then we could have the legacy "big bucket" sysbus
> bus that nobody may ever dynamically put devices into. For CCSR we could
> create another bucket that the machine file can control where each
> device goes and can also detect if a device doesn't fit. And then we
> just declare the virt "platform bus" sysbus the default bus for cmdline
> -device sysbusdevice and everything resolves automatically.
next prev parent reply other threads:[~2014-09-10 10:06 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-09 7:54 [Qemu-devel] [PATCH v3 0/6] machvirt dynamic sysbus device instantiation Eric Auger
2014-09-09 7:54 ` [Qemu-devel] [PATCH v3 1/6] hw/misc/dyn_sysbus_binding: helpers for sysbus device dynamic binding Eric Auger
2014-09-09 10:56 ` Paolo Bonzini
2014-09-09 15:25 ` Eric Auger
2014-09-09 15:59 ` Paolo Bonzini
2014-09-09 16:11 ` Eric Auger
2014-09-10 9:31 ` Alexander Graf
2014-09-10 9:43 ` Paolo Bonzini
2014-09-10 9:56 ` Alexander Graf
2014-09-10 10:05 ` Paolo Bonzini [this message]
2014-09-10 10:09 ` Alexander Graf
2014-09-10 10:21 ` Paolo Bonzini
2014-09-10 10:26 ` Alexander Graf
2014-09-10 10:34 ` Paolo Bonzini
2014-09-10 13:51 ` Eric Auger
2014-09-10 14:18 ` Paolo Bonzini
2014-09-10 14:38 ` Alexander Graf
2014-09-10 14:39 ` Paolo Bonzini
2014-09-10 15:21 ` Alexander Graf
2014-09-10 10:06 ` Paolo Bonzini
2014-09-09 7:54 ` [Qemu-devel] [PATCH v3 2/6] hw/arm/dyn_sysbus_devtree: helpers for sysbus device dynamic dt node generation Eric Auger
2014-09-09 11:04 ` Paolo Bonzini
2014-09-09 14:39 ` Peter Crosthwaite
2014-09-09 15:56 ` Eric Auger
2014-09-09 16:00 ` Peter Maydell
2014-09-09 16:08 ` Eric Auger
2014-09-09 16:03 ` Paolo Bonzini
2014-09-09 16:11 ` Eric Auger
2014-09-09 7:54 ` [Qemu-devel] [PATCH v3 3/6] PPC: e500: use dyn_sysbus_binding helper routines Eric Auger
2014-09-09 7:54 ` [Qemu-devel] [PATCH v3 4/6] hw/arm/boot: load_dtb becomes non static arm_load_dtb Eric Auger
2014-09-09 7:54 ` [Qemu-devel] [PATCH v3 5/6] hw/arm/virt: new add_fdt_*_node functions Eric Auger
2014-09-09 11:06 ` Paolo Bonzini
2014-09-09 7:54 ` [Qemu-devel] [PATCH v3 6/6] hw/arm/virt: Support dynamically spawned sysbus devices Eric Auger
2014-09-09 11:11 ` Paolo Bonzini
2014-09-09 11:17 ` Peter Maydell
2014-10-20 14:41 ` Eric Auger
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=54102258.4040503@redhat.com \
--to=pbonzini@redhat.com \
--cc=Bharat.Bhushan@freescale.com \
--cc=a.motakis@virtualopensystems.com \
--cc=a.rigo@virtualopensystems.com \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=alex.williamson@redhat.com \
--cc=christoffer.dall@linaro.org \
--cc=eric.auger@linaro.org \
--cc=eric.auger@st.com \
--cc=joel.schopp@amd.com \
--cc=kim.phillips@freescale.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=manish.jaggi@caviumnetworks.com \
--cc=marc.zyngier@arm.com \
--cc=patches@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stuart.yoder@freescale.com \
--cc=will.deacon@arm.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).