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

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Mon, Apr 11, 2011 at 20:55, Jan Kiszka <jan.kiszka@xxxxxx> 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 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel