Hi, Am 22.05.2014 04:33, schrieb chen.fan.f...@cn.fujitsu.com: > I think if we want to use 'device/device_add' to implement CPU, > we must do some check before qemu_init_vcpu(). how can we to do that?
We ran into such problems before... If need be, we can change from the old parent_realize scheme to the base class calling the derived realize function in-order, or we can add new hooks to CPUClass as necessary. Consider me a bit skeptical about MAX_CPUMASK_BITS in 1/3. This should at least be tied to the maximum allowed for QEMUMachine/MachineClass rather than hardcoded to 255, which people may forget to synchronize. There was a recent attempt to increase the limits. 2/3 looks good apart from the subject; I could cherry-pick that, seeing there is Reviewed-by, if you like. 3/3 is doing a bit much to digest at once for my taste. Regards, Andreas > On Tue, 2014-05-13 at 18:08 +0800, Chen Fan wrote: >> this patches tried to make cpu hotplug with device_add, >> and made -device foo-x86_64-cpu available,also we can >> set apic-id property with command line, if without setting >> apic-id property, we added first unoccupied apic id as the >> default new apic id. and hotplug cpu with device_add, we >> must make check of APIC ID after cpu object initialization >> that was different from 'cpu_add' command which check 'ids' >> at the beginning. >> >> Chen Fan (3): >> using CPUMASK bitmaps to calculate cpu index >> cpu: introduce CpuTopoInfo structure for argument simplification >> cpu: add device_add foo-x86_64-cpu support >> >> exec.c | 9 +++-- >> include/qom/cpu.h | 11 ++++++ >> include/sysemu/sysemu.h | 7 ---- >> qdev-monitor.c | 11 ++++++ >> target-i386/cpu.c | 91 >> ++++++++++++++++++++++++++++++++++++++++++++++++- >> target-i386/topology.h | 51 ++++++++++++++++++--------- >> 6 files changed, 151 insertions(+), 29 deletions(-) -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg