From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= Subject: Re: [Qemu-devel] KVM call minutes July 10th Date: Tue, 10 Jul 2012 19:24:49 +0200 Message-ID: <4FFC6561.10007@suse.de> References: <874npfsm1n.fsf@elfo.mitica> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: KVM devel mailing list , qemu-devel@nongnu.org, Peter Maydell , Paolo Bonzini , Alexander Graf , Anthony Liguori , Blue Swirl , Igor Mammedov , Liu Ping Fan To: quintela@redhat.com Return-path: Received: from cantor2.suse.de ([195.135.220.15]:53267 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754281Ab2GJRYz (ORCPT ); Tue, 10 Jul 2012 13:24:55 -0400 In-Reply-To: <874npfsm1n.fsf@elfo.mitica> Sender: kvm-owner@vger.kernel.org List-ID: Hi, Am 10.07.2012 16:55, schrieb Juan Quintela: >=20 > We discussed this - CPU VMState series by Juan Question: Could we assign CPU-specific VMStateDescription to DeviceState::vmsd? > - cpu_index: is that transmited? Yes (Juan). we need to be sure tha= t > cpu_common and cpu use the same index/whatever it is changed Above answer =3D> maybe. > - We used cpu_index for SEABIOS interface as apic_id (Eduardo) >=20 > - cpu_hotplug makes that difficult. How to pass the apic_id to > seabios with cpu-hotplug? Getting apic_id of a cpu without running > code on that cpu is "tricky" Anthony will look at the code. >=20 > - How to coordinate all changes with cpu hotplug? Anthony and Andrea= s approach. > * Andreas: move softmmu to DeviceState, and let linux-user use curr= ent object This original approach was based on existing include/qemu/cpu.h file. Pro: sharing code Pro: smallest patch Con: no precedence for #ifdef'ed parent > * Anthony1: use different structures for each Uses separate files per structs. Pro: less #ifdefs Pro: "that's how Linux does it" (aliguori) Con: code duplication into multiple separate files > * Anthony2: make linux-user also use DeviceState Pro: cleanest for cpu.h (same .parent everywhere) Con: difficult to build qdev.h in linux-user due to target_phys_addr_t ???: Is it really a device that linux-user uses? (agraf) > [long discussion here, that would be summarized by Andreas?] Why DeviceState? qdev infrastructure including reset, realize, possibly VMState is not being generalized to Object, thus everything that wants to hook into it must be a DeviceState - applies to softmmu only so far. For linux-user/bsd-user there was no requirement yet to actually use any qdev infrastructure. Juan's comment: There are more dimensions than just the discussed softmmu vs. user: softmmu | *-user TCG x x KVM x [Xen did not seem to have special fields in CPUArchState. There have been suggestions to split out KVM fields from CPUState, similar to TLB, no patches yet though.] My proposal: Adopt Anthony1 qdev.h split, adopt Andreas #ifdef approach and adopt Anthony1 approach of having -softmmu and -user files where things largely differ. Optionally revisit exec.c, cpu-exec.c, cpus.c. Anthony's proposal: Adopt Anthony1 patchset, reconsider (fuse back?) once my CPUState field movements get merged. [Note: I would've thought that to be rather soon but the AREG0 changes are making rebasing it a bit of a pain right now.= ] Anthony's proposal #2: Rework CPU interface to be the subset linux-user needs, build something around it for softmmu. No volunteers or concrete suggestions so far. Anthony's CONFIG_ARCH_* (v2 upcoming) was agreed as prerequisite to moving some cpu.h code [cpu_clone_regs()] into linux-user/, independent of the QOM CPU modelling. CPU hotplug is considered nice-to-have for v1.2 but no release blocker. =3D> AF: If there is an urgent need to have qdev for making progress wi= th hotplug, apply any sanitized solution now, with the option of refactoring it for code reuse shortly after again. Else, defer decision to review of alternative patch series, better showing the effects. Igor and Ping Fan were not on the call, so no action/merge plan was tapped out yet. [Please coordinate among each others, thanks.] Hope I managed to summarize somewhat objectively. ;) Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrn= berg From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoeBJ-0007Vw-Ev for qemu-devel@nongnu.org; Tue, 10 Jul 2012 13:25:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SoeBH-0005vW-D4 for qemu-devel@nongnu.org; Tue, 10 Jul 2012 13:25:01 -0400 Received: from cantor2.suse.de ([195.135.220.15]:53269 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoeBH-0005ur-2f for qemu-devel@nongnu.org; Tue, 10 Jul 2012 13:24:59 -0400 Message-ID: <4FFC6561.10007@suse.de> Date: Tue, 10 Jul 2012 19:24:49 +0200 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <874npfsm1n.fsf@elfo.mitica> In-Reply-To: <874npfsm1n.fsf@elfo.mitica> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] KVM call minutes July 10th List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: quintela@redhat.com Cc: Peter Maydell , Liu Ping Fan , KVM devel mailing list , Alexander Graf , qemu-devel@nongnu.org, Blue Swirl , Anthony Liguori , Igor Mammedov , Paolo Bonzini Hi, Am 10.07.2012 16:55, schrieb Juan Quintela: >=20 > We discussed this - CPU VMState series by Juan Question: Could we assign CPU-specific VMStateDescription to DeviceState::vmsd? > - cpu_index: is that transmited? Yes (Juan). we need to be sure that > cpu_common and cpu use the same index/whatever it is changed Above answer =3D> maybe. > - We used cpu_index for SEABIOS interface as apic_id (Eduardo) >=20 > - cpu_hotplug makes that difficult. How to pass the apic_id to > seabios with cpu-hotplug? Getting apic_id of a cpu without running > code on that cpu is "tricky" Anthony will look at the code. >=20 > - How to coordinate all changes with cpu hotplug? Anthony and Andreas = approach. > * Andreas: move softmmu to DeviceState, and let linux-user use curren= t object This original approach was based on existing include/qemu/cpu.h file. Pro: sharing code Pro: smallest patch Con: no precedence for #ifdef'ed parent > * Anthony1: use different structures for each Uses separate files per structs. Pro: less #ifdefs Pro: "that's how Linux does it" (aliguori) Con: code duplication into multiple separate files > * Anthony2: make linux-user also use DeviceState Pro: cleanest for cpu.h (same .parent everywhere) Con: difficult to build qdev.h in linux-user due to target_phys_addr_t ???: Is it really a device that linux-user uses? (agraf) > [long discussion here, that would be summarized by Andreas?] Why DeviceState? qdev infrastructure including reset, realize, possibly VMState is not being generalized to Object, thus everything that wants to hook into it must be a DeviceState - applies to softmmu only so far. For linux-user/bsd-user there was no requirement yet to actually use any qdev infrastructure. Juan's comment: There are more dimensions than just the discussed softmmu vs. user: softmmu | *-user TCG x x KVM x [Xen did not seem to have special fields in CPUArchState. There have been suggestions to split out KVM fields from CPUState, similar to TLB, no patches yet though.] My proposal: Adopt Anthony1 qdev.h split, adopt Andreas #ifdef approach and adopt Anthony1 approach of having -softmmu and -user files where things largely differ. Optionally revisit exec.c, cpu-exec.c, cpus.c. Anthony's proposal: Adopt Anthony1 patchset, reconsider (fuse back?) once my CPUState field movements get merged. [Note: I would've thought that to be rather soon but the AREG0 changes are making rebasing it a bit of a pain right now.] Anthony's proposal #2: Rework CPU interface to be the subset linux-user needs, build something around it for softmmu. No volunteers or concrete suggestions so far. Anthony's CONFIG_ARCH_* (v2 upcoming) was agreed as prerequisite to moving some cpu.h code [cpu_clone_regs()] into linux-user/, independent of the QOM CPU modelling. CPU hotplug is considered nice-to-have for v1.2 but no release blocker. =3D> AF: If there is an urgent need to have qdev for making progress with hotplug, apply any sanitized solution now, with the option of refactoring it for code reuse shortly after again. Else, defer decision to review of alternative patch series, better showing the effects. Igor and Ping Fan were not on the call, so no action/merge plan was tapped out yet. [Please coordinate among each others, thanks.] Hope I managed to summarize somewhat objectively. ;) Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg