On 2012-01-24 17:24, Igor Mammedov wrote: > On 01/23/2012 06:55 PM, Jan Kiszka wrote: >> On 2012-01-23 17:29, Igor Mammedov wrote: >>> On 01/17/2012 03:17 PM, Jan Kiszka wrote: >>> >>> It seams that "env->cpuid_apic_id = cpu" is pointless especcialy >>> taking in account that in cpu_x86_init cpuid_apic_id is initialized >>> by cpu_index. >>> What we gain in having cpuid_apic_id that actually duplicate cpu_index? >>> May be there is sence to get rid of cpuid_apic_id? >> >> cpu_index is for internal counting (I think to remember that, >> cpuid_apic_id is the ID exposed to the guest. During CPU hotplug, you >> can control this by virtually plugging the CPU in a specific slot. So we >> need to pass this ID down the init chain - just not set it in generic code. > > It could be set in target specific new_cpu, it is not necessary to change > whole cpu_init call chain and affect all other targets that might be not > interested in this change at all. > >> >>> >>> Another question is about how hot-plug/unplug should be designed: >>> 1st approach: >>> With the current code we can't create vcpu with specific index. >> >> Forget about index, the apic_id is important to control. And that could >> become something like -cpu XXX,apid_id=N. Of course, collisions need to >> be detected and rejected. >> >>> But we can implement xen like approach, where hot-plug command says >>> which amount of active vcpus guest should have. This way we can >>> leave current cpu_init -> cpu_x86_init -> cpu_exec_init call >>> chain without change and plug/unplug next/last vcpu. >>> >>> 2nd approach: >>> Ability to plug/unplug individual vcpus based on their cpu_index. >>> to do this we need add cpu_index argument to cpu_init -> >>> cpu_x86_init -> cpu_exec_init call chain. It will look more >>> like the real hardware cpu hot-plug, but do virtual guests really >>> need it. And what for if this way is more preferrable than the 1st. >>> > > Jan, > > Am I right in assuming that you are in a favor of 2nd approach with correction > that some opaque cpu ID (in case of x86 it will be apic_id) will be passed > down > to new_cpu?
I'm in favor of "device_add <cputype>,apic_id=<N>" and that the apic_id becomes a qdev property. That way you would not need to pass anything down, the device (cpu) init code could pick it up on its own. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
