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.0 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 4EF90C388F7 for ; Tue, 10 Nov 2020 10:06:24 +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 871CC20797 for ; Tue, 10 Nov 2020 10:06:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="NtP+OdH7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 871CC20797 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:35410 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcQXe-0007nB-Hx for qemu-devel@archiver.kernel.org; Tue, 10 Nov 2020 05:06:22 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58356) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcQWX-0007Bn-Lp for qemu-devel@nongnu.org; Tue, 10 Nov 2020 05:05:13 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:22288) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1kcQWS-0006Cd-N5 for qemu-devel@nongnu.org; Tue, 10 Nov 2020 05:05:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605002706; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=neGUqwK37S/LipoFHuZSq7cEMep/9j2GnMJpXLVLlUg=; b=NtP+OdH7lN2nEswUaZaiVDIJeirwkAU7W1FJ/c/w0xUJOZCA4SBg9JtlO5B3BigNnVnQaD YhivKCP6z79HPhXYI4K4067wlDsyPBnieajB1f7iiEqOef5YJu8A6Ky31xnyUYTKKSa5rh 74WY3vy4W4U2Zo7VJo4Wch8UzQZLImE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-140-kPl9ndvcPmOcfEQNVVIDdw-1; Tue, 10 Nov 2020 05:04:53 -0500 X-MC-Unique: kPl9ndvcPmOcfEQNVVIDdw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EEE7D186DD23; Tue, 10 Nov 2020 10:04:50 +0000 (UTC) Received: from redhat.com (ovpn-115-68.ams2.redhat.com [10.36.115.68]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3ED7550B44; Tue, 10 Nov 2020 10:04:42 +0000 (UTC) Date: Tue, 10 Nov 2020 10:04:38 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Claudio Fontana Subject: Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration Message-ID: <20201110100438.GF866671@redhat.com> References: <20201109172755.16500-1-cfontana@suse.de> <20201109172755.16500-10-cfontana@suse.de> <20201109180302.GB814975@redhat.com> <971cfde9-d24e-a3dc-6389-8a7c9e477f63@suse.de> MIME-Version: 1.0 In-Reply-To: <971cfde9-d24e-a3dc-6389-8a7c9e477f63@suse.de> User-Agent: Mutt/1.14.6 (2020-07-11) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=63.128.21.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/10 00:21:06 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=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: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 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 , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Richard Henderson , Colin Xu Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" 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 -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|