Am 24.02.2012 14:05, schrieb Igor Mammedov: > On 02/17/2012 06:02 PM, Igor Mammedov wrote: >> So I'd rather drop ICC patch and try your approach with CPU links<>, I >> see no >> point in introducing new bus providing we have an alternative model >> and existing >> bus for the task. > > I've looked at device_add command and qdev_device_add it uses for doing > actual work > and in current state it requires (based on Andreas' qom_cpu branch): > > For approach where apic and cpu hot-plugged to sysbus. > 1. created object must be descendant of TYPE_DEVICE. So QOM TYPE_CPU > should be inherited > from TYPE_DEVICE at least or TYPE_SYS_BUS_DEVICE. > 2. hot-plug on the bus should be allowed. if we ditch icc bus then we > should allow > hot-plug on sysbus. Can we do this? (i.e. it seems that for P4 and > later cpus > sysbus should be hot-plugable). > 3. should DeviceClass.init be used for cpu initialization or should > .instance_init > do all the job and make DeviceClass.init nop?
SysBus is supposed to go away in Anthony's upcoming 4th QOM series, so I'd rather not base a new series on that. The issue with TYPE_DEVICE is that we don't want to leak that into the user emulators (would break the build), and any infrastructure only available to qdev should gradually be made accessible to all objects (Paolo has done some work in that direction wrt properties). So the main remaining difference between Object and Device is the GPIO IRQ support. Anthony wanted to introduce Pin objects to replace qemu_irq. As for init, the idea was to have initialization code in an initfn, the resulting state is then supposed to be overridable by the user (e.g., set family, model, stepping differently on the CPU) and then do the construction work in a realize function that corresponds more closely to DeviceClass::init. This too, still needs to be generalized. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg