| Message ID | 20240208181245.96617-1-philmd@linaro.org |
|---|---|
| Headers | show |
| Series | hw: Strengthen SysBus & QBus API | expand |
On 2/8/24 19:12, Philippe Mathieu-Daudé wrote: > Hi, > > This series ensure following is called *before* a > device is realized: > - qbus_new() > - sysbus_init_mmio() > - qdev_init_gpio_in_named_with_opaque() > > and these are called *after* it is: > - sysbus_mmio_map() > - sysbus_connect_irq(), > - qdev_connect_gpio_out() > - qdev_connect_gpio_out_named() This series is missing a _why_. The original vision for qdev was that the whole machine would be realized at once from vl.c, and therefore there would be no need for realizing subcomponents by hand. This probably will never happen, but it is still worth explaining why it's now considered so conceptually wrong, that it is (or will be) enforced by the API. Paolo > Patches from v2 enforcing these checks will be posted > in a separate series. > > Philippe Mathieu-Daudé (11): > hw/ide/ich9: Use AHCIPCIState typedef > hw/rx/rx62n: Reduce inclusion of 'qemu/units.h' > hw/rx/rx62n: Only call qdev_get_gpio_in() when necessary > hw/i386/pc_q35: Realize LPC PCI function before accessing it > hw/ppc/prep: Realize ISA bridge before accessing it > hw/misc/macio: Realize IDE controller before accessing it > hw/sh4/r2d: Realize IDE controller before accessing it > hw/sparc/sun4m: Realize DMA controller before accessing it > hw/sparc/leon3: Realize GRLIB IRQ controller before accessing it > hw/sparc/leon3: Initialize GPIO before realizing CPU devices > hw/sparc64/cpu: Initialize GPIO before realizing CPU devices > > include/hw/rx/rx62n.h | 2 -- > hw/i386/pc_q35.c | 2 +- > hw/ide/ich.c | 6 +++--- > hw/misc/macio/macio.c | 8 +++++--- > hw/ppc/prep.c | 2 +- > hw/rx/rx-gdbsim.c | 1 + > hw/rx/rx62n.c | 17 +++++++++-------- > hw/sh4/r2d.c | 2 +- > hw/sparc/leon3.c | 11 ++++++----- > hw/sparc/sun4m.c | 7 +++++-- > hw/sparc64/sparc64.c | 4 +++- > 11 files changed, 35 insertions(+), 27 deletions(-) >
On 11/10/24 05:56, Paolo Bonzini wrote: > On 2/8/24 19:12, Philippe Mathieu-Daudé wrote: >> Hi, >> >> This series ensure following is called *before* a >> device is realized: >> - qbus_new() >> - sysbus_init_mmio() >> - qdev_init_gpio_in_named_with_opaque() >> >> and these are called *after* it is: >> - sysbus_mmio_map() >> - sysbus_connect_irq(), >> - qdev_connect_gpio_out() >> - qdev_connect_gpio_out_named() > > This series is missing a _why_. The original vision for qdev was that > the whole machine would be realized at once from vl.c, and therefore > there would be no need for realizing subcomponents by hand. > > This probably will never happen, but it is still worth explaining why > it's now considered so conceptually wrong, that it is (or will be) > enforced by the API. When looking at a roadmap toward "dynamic machines" with Markus we needed to clarify the QOM life cycle before thinking about possible DSL to declare machines and components. See: = Problem 4: The /machine/unattached/ orphanage = = Problem 5: QOM lacks a clear life cycle = = Problem 7: Design of the machine specification DSL = in https://lore.kernel.org/qemu-devel/87o7d1i7ky.fsf@pond.sub.org/, in particular: ''' We need to manage a state transition from "object created, but not ready for use" to "object configured and ready for use". In what order do the objects change state? ''' and: ''' Ideally, a composite object's components go through the life cycle together. First, create all the components and assign parents. This also creates all the properties. Then configure the object by setting property values. Finally, complete / realize all components. ''' We need a better QOM documentation, "Device Life-cycle" in docs/devel/qom.rst doesn't reallyr describe the life cycle, and doesn't mention the "realization" API contract. Since you have more experience and historical view on the APIs, I wouldn't mind if you want to clarify that; otherwise I'll try to do it. Regards, Phil. > Paolo