Re: [Qemu-devel] [PATCH 2/3] VCPU hotplug support

[Igor Mammedov <imammedo@redhat.com>]

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?

-- 
Thanks,
  Igor