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
signature.asc
Description: OpenPGP digital signature
