From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9BD77C388F7 for ; Tue, 10 Nov 2020 10:14:23 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E949820797 for ; Tue, 10 Nov 2020 10:14:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E949820797 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:44560 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcQfN-0003QP-Ui for qemu-devel@archiver.kernel.org; Tue, 10 Nov 2020 05:14:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60480) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcQed-0002pM-Mi for qemu-devel@nongnu.org; Tue, 10 Nov 2020 05:13:35 -0500 Received: from mx2.suse.de ([195.135.220.15]:50192) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcQeY-0000cL-Ba for qemu-devel@nongnu.org; Tue, 10 Nov 2020 05:13:35 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 0152FAF27; Tue, 10 Nov 2020 10:13:29 +0000 (UTC) Subject: Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration To: =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= References: <20201109172755.16500-1-cfontana@suse.de> <20201109172755.16500-10-cfontana@suse.de> <20201109180302.GB814975@redhat.com> <971cfde9-d24e-a3dc-6389-8a7c9e477f63@suse.de> <20201110100438.GF866671@redhat.com> From: Claudio Fontana Message-ID: Date: Tue, 10 Nov 2020 11:13:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201110100438.GF866671@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=195.135.220.15; envelope-from=cfontana@suse.de; helo=mx2.suse.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/09 23:19:25 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x (no timestamps) [generic] X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Laurent Vivier , Thomas Huth , Stefano Stabellini , Eduardo Habkost , Paul Durrant , Jason Wang , Marcelo Tosatti , qemu-devel@nongnu.org, Peter Xu , Dario Faggioli , Roman Bolshakov , Wenchao Wang , haxm-team@intel.com, Cameron Esfahani , Anthony Perard , Paolo Bonzini , Sunil Muthuswamy , Bruce Rogers , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , Richard Henderson , Colin Xu Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 11/10/20 11:04 AM, Daniel P. Berrangé wrote: > On Tue, Nov 10, 2020 at 10:40:04AM +0100, Claudio Fontana wrote: >> On 11/9/20 7:03 PM, Daniel P. Berrangé wrote: >>> On Mon, Nov 09, 2020 at 06:27:54PM +0100, Claudio Fontana wrote: >>>> split cpu.c into: >>>> >>>> cpu.c cpuid and common x86 cpu functionality >>>> host-cpu.c host x86 cpu functions and "host" cpu type >>>> kvm-cpu-type.c KVM x86 cpu type >>>> hvf-cpu-type.c HVF x86 cpu type >>>> tcg-cpu-type.c TCG x86 cpu type >>>> >>>> Defer the x86 models registration to MODULE_INIT_ACCEL_CPU, >>>> so that accel-specific types can be used as parent types for all >>>> cpu models. Use the generic TYPE_X86_CPU only if no >>>> accel-specific specialization is enabled. >>> >>> Can you give more info on why this is needed and/or desirable ? >> >> Hello Daniel, there is a pointer to the overall higher level motivation in the cover letter. >> >> But I am not pushing for this specific mechanism to be used, as mentioned in the cover letter. >> >> If we need another mechanism to achieve that (not delaying the x86 model registration and make them inherit from the specialized class), but something else, >> I would be happy to get additional ideas. >> >>> >>> Dynamically changing the class hierarchy of CPUs at runtime feels >>> like a rather suspicious approach to me >> >> TYPE_X86_CPU is base type is registered as usual. >> New accel-specialized types are defined (TYPE_TCG_CPU, TYPE_KVM_CPU, TYPE_HVF_CPU), also using normal type registration. >> >> The missing step is how to adapt all the cpu models to use the functionality. > > If I understand the problem correctly, we have two distinct axis of > configurability > > - the CPU model definitions (Nehalem, Broadwell, Skylake, host, max) > - the accelerator CPU implementations (tcg, kvm, hvf). > > At runtime any pair of objects from these two axis can be combined. > > We're trying to avoid defining classes for the combinatorial expansion > of these axis. > > This patch series encodes these two axis in a single class hierarchy, > with the CPU implementations being a parent of the CPU model definitions. > It avoids the combinatorial expansion, by taking the approach of dynamically > defining the parent/child relation between CPU impl and CPU defintion at > runtime baed on the choosen accelerator impl. > > The fully static way to deal with this problem is to accept that distinct > axis should be represented as distinct class hierarchies. > > ie, we should have one class hierarchy for CPU model definitions, and > one class hierarchy for accelerator CPU implementations. > > So at runtime we then get two object instances - a CPU implementation > and a CPU definition. The CPU implementation object should have a > property which is a link to the desired CPU definition. > > >> The accelerator that is finally chosen to be used is only known at a specific point in the qemu initialization. >> This point of time I defined as MODULE_INIT_ACCEL_CPU. >> >> That is the time when we know how the CPU should actually really behave (how it should be realized, etc). >> >> In this series I realized this by registering the cpu models only at MODULE_INIT_ACCEL_CPU time, and not earlier. >> But maybe there is a better idea on how to do it, and I am all ears. >> >> . >>> >>> It is contrary to work we've been doing recently to try to make all >>> classes be fully statically defined by getting rid of dynamic properties, >>> such that introspection of classes does not depend on other CLI flags >>> you might have passed. >> >> Understood, this goes against other requirements. >> >> The dynamism introduced here is to register the cpu models at MODULE_INIT_ACCEL_CPU time instead of MODULE_INIT_QOM time. >> As a result, for any chosen accelerator, the type tree and class tree is identical. > > For introspection the goal is that the type tree and class tree is > identical for a *binary*, not an accelerator within a binary. > > > Regards, > Daniel > Thanks Daniel for your comments, I am going to think these through and see if I can build a model like you suggest (with the cpu implementation axis separate from the cpu model definitions axis), as a possible other way forward. Ciao, Claudio