From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60974) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpjAf-0006Y6-Ii for qemu-devel@nongnu.org; Tue, 24 Jan 2012 11:24:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpjAe-0000dR-FI for qemu-devel@nongnu.org; Tue, 24 Jan 2012 11:24:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1461) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpjAe-0000dC-6m for qemu-devel@nongnu.org; Tue, 24 Jan 2012 11:24:32 -0500 Message-ID: <4F1EDB38.5050807@redhat.com> Date: Tue, 24 Jan 2012 17:24:24 +0100 From: Igor Mammedov MIME-Version: 1.0 References: <1326806230-2734-1-git-send-email-imammedo@redhat.com> <1326806230-2734-3-git-send-email-imammedo@redhat.com> <4F1582E2.9080007@siemens.com> <4F1D8ADD.4000306@redhat.com> <4F1D9F06.1040404@siemens.com> In-Reply-To: <4F1D9F06.1040404@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/3] VCPU hotplug support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "pingfank@linux.vnet.ibm.com" , "qemu-devel@nongnu.org" , "gleb@redhat.com" , Juan Quintela On 01/23/2012 06:55 PM, Jan Kiszka wrote: > On 2012-01-23 17:29, Igor Mammedov wrote: >> On 01/17/2012 03:17 PM, Jan Kiszka wrote: >> >> It seams that "env->cpuid_apic_id = cpu" is pointless especcialy >> taking in account that in cpu_x86_init cpuid_apic_id is initialized >> by cpu_index. >> What we gain in having cpuid_apic_id that actually duplicate cpu_index? >> May be there is sence to get rid of cpuid_apic_id? > > cpu_index is for internal counting (I think to remember that, > cpuid_apic_id is the ID exposed to the guest. During CPU hotplug, you > can control this by virtually plugging the CPU in a specific slot. So we > need to pass this ID down the init chain - just not set it in generic code. It could be set in target specific new_cpu, it is not necessary to change whole cpu_init call chain and affect all other targets that might be not interested in this change at all. > >> >> Another question is about how hot-plug/unplug should be designed: >> 1st approach: >> With the current code we can't create vcpu with specific index. > > Forget about index, the apic_id is important to control. And that could > become something like -cpu XXX,apid_id=N. Of course, collisions need to > be detected and rejected. > >> But we can implement xen like approach, where hot-plug command says >> which amount of active vcpus guest should have. This way we can >> leave current cpu_init -> cpu_x86_init -> cpu_exec_init call >> chain without change and plug/unplug next/last vcpu. >> >> 2nd approach: >> Ability to plug/unplug individual vcpus based on their cpu_index. >> to do this we need add cpu_index argument to cpu_init -> >> cpu_x86_init -> cpu_exec_init call chain. It will look more >> like the real hardware cpu hot-plug, but do virtual guests really >> need it. And what for if this way is more preferrable than the 1st. >> Jan, Am I right in assuming that you are in a favor of 2nd approach with correction that some opaque cpu ID (in case of x86 it will be apic_id) will be passed down to new_cpu? -- Thanks, Igor