Andreas Färber <afaer...@suse.de> writes: > Hi Markus, > > Am 15.10.2013 14:24, schrieb Markus Armbruster: >> To go beyond RFC with this series, I need to explain why TYPE_CPU >> cannot_instantiate_with_device_add_yet. Would you be so kind and help >> me out with a suitable comment? > >>From what I remember this was done when I started the whole process and > most CPU subtypes did not yet use the QOM instance_init for > initialization. Most importantly x86 still is not yet self-contained, > nor is sparc. Such targets need to use cpu_init() et al. rather than > -device. (This became visible in the first s390x vCPU hotplug series.) > > Most boards rely on being able to do postprocessing after they have > instantiated the CPU: wiring up IRQs, adding reset handlers, halting > non-first CPUs, ... > -device would skip that.
This is the prime reason for cannot_instantiate_with_device_add_yet. > Another aspect is that no CPU subtype has been proven hot-pluggable with > device_add yet. For s390x we're the closest to date. Hot-plug support is orthogonal. We got plenty of devices that support device-add, but only cold plug. > We could move the flag from the base type to the targets' base types if > you prefer. Then we can knock the bad values out one by one rather than > overriding the inherited value with an explicit positive one. I'd prefer to make that move when the first CPU is ready. Thanks! [...]
