On Fri, Mar 24, 2017 at 02:13:48PM +0000, Peter Maydell wrote: > On 24 March 2017 at 13:48, Eduardo Habkost <ehabk...@redhat.com> wrote: > > The problem with today's mechanism is that we have no way to make > > a machine accept one type of sysbus device without making it > > start accepting every other sysbus devices. If we thought all > > !cannot_instantiate_with_device_add_yet sysbus devices were > > already safe, we wouldn't have has_dynamic_sysbus in the first > > place, would we? > > Almost all sysbus devices are not dynamically instantiable > and never will be [...]
Exactly. But most of them do _not_ have cannot_instantiate_with_device_add_yet set. What I don't know is: should they? > [...] because they need to map mmio and wire > up IRQs and so on, and we have no mechanism for doing that. > So the default position is "no, you can't do that (but maybe > a subclass which knows better might override)". has_dynamic_sysbus > is a dodgy hack for boards which support the "platform bus" > which is a special case where the user can use -device > for certain sysbus devices that the platform bus knows about > and can wire up itself (in a range of irqs and memory that > the board has set aside for that purpose). The default > is still "no, you can't dynamically instantiate this", but > instead of this (and the handful of exceptions) being imposed > at compile time it's imposed (with exceptions) at runtime. > > So for instance the ARM 'virt' board sets has_dynamic_sysbus, > which allows a few devices to be added with -device, but > most still do not permit it (they'll end up hitting the > error_report() in hw/arm/sysbus-fdt.c:add_fdt_node()). I sent a series yesterday that implements a generic mechanism for boards to set the list of accepted device types, to replace has_dynamic_sysbus. That part was easy. But I still don't know what to do about q35. -- Eduardo