From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WL9z1-0006KK-7S for qemu-devel@nongnu.org; Wed, 05 Mar 2014 06:27:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WL9yt-0001e0-Tm for qemu-devel@nongnu.org; Wed, 05 Mar 2014 06:27:31 -0500 Received: from mail-pd0-f182.google.com ([209.85.192.182]:63232) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WL9yt-0001dr-OW for qemu-devel@nongnu.org; Wed, 05 Mar 2014 06:27:23 -0500 Received: by mail-pd0-f182.google.com with SMTP id g10so945735pdj.27 for ; Wed, 05 Mar 2014 03:27:22 -0800 (PST) Message-ID: <53170A15.4060902@ozlabs.ru> Date: Wed, 05 Mar 2014 22:27:17 +1100 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1393901749-5944-1-git-send-email-afaerber@suse.de> <531690FB.7060801@ozlabs.ru> <5316E094.2020508@suse.de> In-Reply-To: <5316E094.2020508@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH qom-cpu 0/6] cpu: Unifying features parsing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , qemu-devel@nongnu.org Cc: Igor Mammedov , Eduardo Habkost , Anthony Liguori , Peter Maydell On 03/05/2014 07:30 PM, Andreas Färber wrote: > Am 05.03.2014 03:50, schrieb Alexey Kardashevskiy: >> On 03/04/2014 01:55 PM, Andreas Färber wrote: >>> Hello, >>> >>> Prompted by Alexey's desire for tweakable PowerPCCPU properties but also by >>> Peter's wish for ARMCPU properties, this series sets out to align cpu_model >>> parsing across targets. >>> >>> QemuOpts would've been nice to use, but on the one hand x86 and sparc use >>> QemuOpts-incompatible +foo and -foo syntax (which accumulate rather than apply >>> immediately) and on the other linux-user and bsd-user don't use QemuOpts at all. >>> >>> The x86 implementation is closest to the proposed API, save for some laziness. >>> SPARC is brought in line. And as fallback for the remaining targets a new >>> implementation, derived from x86 but supporting only key=value format, is added. >>> >>> To facilitate using this infrastructure, a generic CPU init function is created. >> >> >> Besides the fact that this patchset does not support dynamic properties >> (added by object_property_add(), and I used it in my initial patchset), > > Why would that be? I am using QOM object_property_parse() just like on > x86 where we do have a mix of static and dynamic properties. Maybe you > are using object_property_add() in the wrong place? It should be used in > the instance_init function of the CPU - be it PowerPCCPU or a derived > family/model - i.e. before cpu_ppc_init() returns. The same is necessary > to support -global. cpu_ppc_init() calls cpu_generic_init() which does parsing before setting "realized" to "true". The only way to add a dynamic property here is to put object_property_add() in ppc_cpu_initfn() but it does not have CPU family hooks (unlike realizefn). Adding "compat" for every PPC CPU is ... wrong? Where I tried adding dynamic property before is init_proc_POWER7 (PowerPCCPUClass::init_proc) which is called from init_ppc_proc() which is called from ppc_cpu_realizefn() and this is too late. > >> that works for SPAPR, just need to implement property statically (tested). > > Thanks, > Andreas > -- Alexey