[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/3] VCPU hotplug support
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [PATCH 2/3] VCPU hotplug support |
Date: |
Tue, 24 Jan 2012 17:37:47 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
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
[Qemu-devel] [PATCH 3/3] add cpu_set qmp command, Igor Mammedov, 2012/01/17