| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [PATCH V12 05/17] xen: Add xenfv machine
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home