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.
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.