Re: [Qemu-devel] [PATCH 2/7] Convert pc cpu to qdev

[Igor Mammedov <imammedo@redhat.com>]

On 03/14/2012 08:59 AM, Lai Jiangshan wrote:
> On 03/13/2012 07:04 PM, Andreas Färber wrote:
>> Am 13.03.2012 10:32, schrieb Lai Jiangshan:
>>> On 02/16/2012 08:51 PM, Anthony Liguori wrote:
>>>> On 02/16/2012 06:01 AM, Jan Kiszka wrote:
>>>>> On 2012-02-16 00:16, Igor Mammedov wrote:
>>>>>> +static ICCBusDeviceInfo cpu_device_info = {
>>>>>> +    .qdev.name = "cpu-pc",
>>>>>> +    .qdev.size = sizeof(CPUPC),
>>>>>> +    .qdev.reset = cpu_device_reset,
>>>>>> +    .init = cpu_device_init,
>>>>>> +    .qdev.props = (Property[]) {
>>>>>> +        DEFINE_PROP_STRING("model", CPUPC, model),
>>>>>
>>>>> And how do you pass in feature flags? Or the core layout? Basically both
>>>>> -cpu and -smp need to be expressible via multiple "-device cpu-x86,xxx"
>>>>> (not "pc") commands.
>>>>
>>>> The approach that I'd recommend is:
>>>>
>>>> 1) convert CPU_COMMON_STATE to a structure named CPUCommonState, query/replace all references to members of CPU_COMMON_STATE appropriately.
>>>
>>> I just tried this for several days, it will result a huge patch,
>>> it is hard for human, any suggestion?
>>> (I used Semantic patches script: http://coccinelle.lip6.fr/, it is still hard,
>>> it still leaves huge part which needs manual conversion/fix)
>>>
>>> I will take part in implementing cpu-hotplug future for qemu,
>>> Could you give me some tips/suggestions? What approach should I take?
>>
>> In short: Don't!
>>
>> Please instead provide feedback on my series which already does
>> something like that for you, available since multiple weeks. If a
>> different naming is preferred, I can change it.
>>
>> The approach I have taken is:
>> 1. CPUState ->  CPU{X86,...}State, CPUArchState as alias where necessary
>> 2. Embed CPU$archState in $archCPU
>> 3. Step by step move CPU_COMMON_STATE from CPUArchState into CPUState
>>
>> Steps 1+2 are done, 2 is partially on the list (e.g., [1]), the rest on
>> my qom-cpu-wip branch [2].
>> Step 3 is shown for icount on qom-cpu-wip as well as for multiple
>> target-specific fields such as target-arm features [3]. Contributions
>> welcome.
>
>
> OK, your work can't be done automatically, but it do be worth when
> there are multiple target-specific fields existed.
>
> Anthony Liguori, Jan Kiszka,
>
> Could you light me what can I do for cpu-hotplug.
> I saw several approaches are sent to the maillist, but they are
> not accepted, so I don't know how to take part in.

As I see it, there is not much to do from cpu hot-plug perspective.
It's just a matter of adaptation QOM-ified cpus for usage from
qdev device_add, and I'm working on it.
However, there is a lot to be done in cpu unplug area:
   - host side: there is unaccepted patches to destroy vcpu
     during VM-lifecycle. They are still need to be worked on:
      "[Qemu-devel] [PATCH 0] A series patches for kvm&qemu to enable vcpu destruction in kvm"
   - linux guest side: kernel can receive ACPI request to unplug cpu,
     but does nothing with it (last time I've tested it with 3.2 kernel),
     You might wish to look at following mail threads:
       https://lkml.org/lkml/2011/9/30/18
       http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02254.html

-- 
-----
  Igor