This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Anthony PERARD <anthony.perard@xxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH V12 05/17] xen: Add xenfv machine
From: Jan Kiszka <jan.kiszka@xxxxxx>
Date: Mon, 11 Apr 2011 21:55:52 +0200
Cc: Alexander Graf <agraf@xxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, QEMU-devel <qemu-devel@xxxxxxxxxx>, Anthony Liguori <anthony@xxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Tue, 12 Apr 2011 22:54:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.1.10.1104111852190.9096@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1301423290-12443-1-git-send-email-anthony.perard@xxxxxxxxxx> <1301423290-12443-6-git-send-email-anthony.perard@xxxxxxxxxx> <4D9F1249.6080305@xxxxxxxxxxx> <alpine.DEB.1.10.1104111852190.9096@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/
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.


Attachment: signature.asc
Description: OpenPGP digital signature

Xen-devel mailing list