[Xen-devel] Re: [PATCH V12 05/17] xen: Add xenfv machine

[Jan Kiszka <jan.kiszka@xxxxxx>]

On 2011-04-11 20:10, Anthony PERARD wrote:
>>>  }
>>>
>>>  static CPUState *pc_new_cpu(const char *cpu_model)
>>> @@ -952,7 +957,12 @@ void pc_cpus_init(const char *cpu_model)
>>>  #endif
>>>      }
>>>
>>> -    for(i = 0; i < smp_cpus; i++) {
>>> +    if (!xen_enabled()) {
>>> +        for(i = 0; i < smp_cpus; i++) {
>>> +            pc_new_cpu(cpu_model);
>>> +        }
>>> +    } else {
>>> +        /* Xen require only one Qemu VCPU */
>>>          pc_new_cpu(cpu_model);
>>
>> This looks a bit fishy. What is the semantic of -smp 2 or more in Xen
>> mode? If that is an invalid/unused configuration option, catch that and
>> reject it instead of installing this workaround. If it has a valid
>> semantic, please elaborate why you need to restrict the number of
>> instantiated cpus. Just to optimize memory usage?
> 
> I thought in a first place that was needed to avoid errors. But it works
> also when we initialise other CPUs. But I prefere to keep it that way to
> save memory and in the case where there is a thread for each cpu that
> will also avoid to have many useless threads.

How much memory does this save? More than a few KB per VCPU? That should
be negligible compared to the normal size of VMs. And as long as we do
not support multi-threaded TCG VCPUs, Xen will only create on thread for
all VCPUs (once that may change, Xen could control the "execution" model
via qemu_init_vcpu).

So I would prefer to avoid this additional Xen-specific branch in
generic code.

Thanks,
Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel