From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony PERARD <anthony.perard@citrix.com>
Subject: Re: [PATCH V12 05/17] xen: Add xenfv machine
Date: Tue, 12 Apr 2011 15:57:50 +0100
Message-ID: <BANLkTincWhTd6WWciScRRP9wn+3+D=okBg@mail.gmail.com>
References: <1301423290-12443-1-git-send-email-anthony.perard@citrix.com>
	<1301423290-12443-6-git-send-email-anthony.perard@citrix.com>
	<4D9F1249.6080305@siemens.com>
	<alpine.DEB.1.10.1104111852190.9096@perard.cam.xci-test.com>
	<4DA35CC8.6030909@web.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <4DA35CC8.6030909@web.de>
List-Unsubscribe: <http://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: </archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Xen Devel <xen-devel@lists.xensource.com>, Alexander Graf <agraf@suse.de>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, QEMU-devel <qemu-devel@nongnu.org>
List-Id: xen-devel@lists.xenproject.org

On Mon, Apr 11, 2011 at 20:55, Jan Kiszka <jan.kiszka@web.de> wrote:
>
> On 2011-04-11 20:10, Anthony PERARD wrote:
> >>> =C2=A0}
> >>>
> >>> =C2=A0static CPUState *pc_new_cpu(const char *cpu_model)
> >>> @@ -952,7 +957,12 @@ void pc_cpus_init(const char *cpu_model)
> >>> =C2=A0#endif
> >>> =C2=A0 =C2=A0 =C2=A0}
> >>>
> >>> - =C2=A0 =C2=A0for(i =3D 0; i < smp_cpus; i++) {
> >>> + =C2=A0 =C2=A0if (!xen_enabled()) {
> >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0for(i =3D 0; i < smp_cpus; i++) {
> >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc_new_cpu(cpu_model);
> >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >>> + =C2=A0 =C2=A0} else {
> >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Xen require only one Qemu VCPU */
> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc_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 an=
d
> >> 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 work=
s
> > also when we initialise other CPUs. But I prefere to keep it that way t=
o
> > 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 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 :).

Thanks,

--
Anthony PERARD