From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9ftm-0006d1-6q for qemu-devel@nongnu.org; Tue, 12 Apr 2011 11:53:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9ftl-0008R5-1T for qemu-devel@nongnu.org; Tue, 12 Apr 2011 11:53:02 -0400 Received: from thoth.sbs.de ([192.35.17.2]:23266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9ftk-0008QW-Ni for qemu-devel@nongnu.org; Tue, 12 Apr 2011 11:53:00 -0400 Message-ID: <4DA47551.90103@siemens.com> Date: Tue, 12 Apr 2011 17:52:49 +0200 From: Jan Kiszka MIME-Version: 1.0 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> <4DA35CC8.6030909@web.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V12 05/17] xen: Add xenfv machine List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony PERARD Cc: Xen Devel , Alexander Graf , Stefano Stabellini , QEMU-devel On 2011-04-12 16:57, Anthony PERARD wrote: > On Mon, Apr 11, 2011 at 20:55, Jan Kiszka 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH V12 05/17] xen: Add xenfv machine Date: Tue, 12 Apr 2011 17:52:49 +0200 Message-ID: <4DA47551.90103@siemens.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> <4DA35CC8.6030909@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: Anthony PERARD Cc: Xen Devel , Alexander Graf , Stefano Stabellini , QEMU-devel List-Id: xen-devel@lists.xenproject.org On 2011-04-12 16:57, Anthony PERARD wrote: > On Mon, Apr 11, 2011 at 20:55, Jan Kiszka 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