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

[Jan Kiszka]

On 2011-04-12 16:57, Anthony PERARD wrote:
> On Mon, Apr 11, 2011 at 20:55, Jan Kiszka <address@hidden> wrote:
>>
>> 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.
> 
> For this patch series, I will remove this Xen specific branch.
> 
> For information, we want to run qemu in a tiny domain (Xen guest) of
> 32MB, so each 30KB per VCPU can count 

I even count 56 KB here (on 64 bit host).

> and in a Xen environment, the VM
> memory is allocated outside of QEMU, by the hypervisor.
> So, we will deal with these extra bytes later, and maybe found a
> better way to do it :).

Well, either you have a use for the VCPU state (how do you do migration
in Xen without it?), or you should probably teach QEMU in a careful &
clean way to run its device model without VCPUs - and without any
TCG-related memory consumption. For the latter, you would likely receive
kudos from KVM people as well.

BTW, if you happen to support that crazy vmport under Xen, not updating
the VCPU state will break your neck. Also, lacking VCPUs prevent the
usage of analysis and debugging features of QEMU (monitor, gdbstub).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux