From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 2002:a19:6d5:0:0:0:0:0 with SMTP id 204csp1084127lfg; Fri, 19 Mar 2021 01:23:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxP15l+bau8FNkOZ8cmRE71dq89lCSz1Hg264qjr7cjXf66aVMUKwtx/YpYgU6H0rVvJm4h X-Received: by 2002:a25:b682:: with SMTP id s2mr4554428ybj.407.1616142238876; Fri, 19 Mar 2021 01:23:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616142238; cv=none; d=google.com; s=arc-20160816; b=rX0NQNMm3/oavmghf/ojOkoIPiw87cQOQdax2u1oroXerjPRVDUTtBqJbB7M89rKnF ZlYRIvrVd9/AKm3sUgtyBfCTYOuFrQkjEYxhOmSHAtFcHPEzD4hwHs3cyL/QIuRZ7OML bVKzkOmX70KbH+ekOXm8ny9DjoVcMNL2xgsO2XTCpPlMQbM4whatl7ppg4YQqcKhexjW 2erw3nxt4p0z+yfQ6+GXYBGloNzQpsHpxyn51AN2b9YFpP/xaNuxC6D//g/0LPTzgBCx LzUBCHAI/AwDT7Sv/yMkLd1gY3OQiXgHEhFNUQV655xUW/289+qcZLMhBXPHtdK73KZl NRdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:cc:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:to:from:subject; bh=0VpbrO1Zl3GZm1MOZvgx++fWBgIOSTgXP+2Qn8O3wxg=; b=WOU8/iMmen1kyY+Ej/P0W2CcPYRZ9/DGqbTjsc7TlSymlaVMaGfKEdHAoeZ75sAMgH CjAFUaasgaqKs7HFz6W9OKwftejOfDA8XXaJ105NcC/J/1Wum8yiTQzeyVNYTIjdAE8P 01Taj0XakW5nI+BiFIQHAi8Mlep3nWQt0ww3i7fLlToW+k0KFd49Tx0uDY4CRrtLDsnK SEJXOjg2st4ZB9SdPA8s+ezL+lKIKf0cPvEYphm5/8Edv3kaXuzwWeNRXApPb5wk0zn6 Oenks7xYMtVD84t1gn7eSU2tw474sAvCz+q+kWutjGQp2g9fCh6DBb0wFhXOqi0YrNcY GfzQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org" Return-Path: Received: from lists.gnu.org (lists.gnu.org. [209.51.188.17]) by mx.google.com with ESMTPS id h26si5162572ybj.310.2021.03.19.01.23.58 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 19 Mar 2021 01:23:58 -0700 (PDT) Received-SPF: pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; Authentication-Results: mx.google.com; spf=pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org" Received: from localhost ([::1]:57124 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lNAQI-0003yT-7o for alex.bennee@linaro.org; Fri, 19 Mar 2021 04:23:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52722) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lNAQ6-0003y4-Dk; Fri, 19 Mar 2021 04:23:46 -0400 Received: from mx2.suse.de ([195.135.220.15]:44960) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lNAQ4-00011Y-GZ; Fri, 19 Mar 2021 04:23:46 -0400 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 E6847AE04; Fri, 19 Mar 2021 08:23:42 +0000 (UTC) Subject: Re: arm_cpu_post_init (Was: Re: arm: "max" CPU class hierarchy changes possible?) From: Claudio Fontana To: Andrew Jones , Peter Maydell , Markus Armbruster References: <11e9d3bb-c94c-4ad7-35b0-b698376c5e00@suse.de> <2e6a5d98-e022-0b39-5f30-92eb74491d3b@redhat.com> <2277fdf5-ec92-476a-8fe5-0d4eee23dfef@suse.de> <20210311191046.ykcelkwq7orajyu7@kamzik.brq.redhat.com> <5467e45c-cc8e-6422-0c56-398405a7c331@suse.de> Message-ID: Date: Fri, 19 Mar 2021 09:23:42 +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: <5467e45c-cc8e-6422-0c56-398405a7c331@suse.de> 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-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-arm@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Eduardo Habkost , Richard Henderson , qemu-devel , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-arm , Paolo Bonzini Errors-To: qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org Sender: "Qemu-arm" X-TUID: 4Jxw17x6Hnyt Hi Markus, could you help me untangle the arm_cpu_post_init question? I am trying to cleanup a bit the initialization path for ARM, and it seems that arm_cpu_post_init is called numerous times for AArch64 in particular, while for "tcg cpus", 32bit it is called only once. Any reason for the multiple calls in the hierarchy? Was the intention to actually call this just once from the final leaf classes? The ability to execute code after the initialization would come in handy in an ARM CPU class refactoring I am doing, but I stopped short of adding anything to arm_cpu_post_init since I noticed the inconsistencies. Thanks, Claudio On 3/18/21 12:06 PM, Claudio Fontana wrote: > On 3/11/21 8:10 PM, Andrew Jones wrote: >> On Thu, Mar 11, 2021 at 06:33:15PM +0000, Peter Maydell wrote: >>> On Thu, 11 Mar 2021 at 17:16, Claudio Fontana wrote: >>>> Maybe Peter you could clarify similarly what the intended meaning of "max" is on ARM? >>> >>> "max" is "best we can do, whatever that is". (On KVM this is "same as >>> the host".) >>> "host" is "whatever the host is (KVM only)". >>> >>>> KVM: (aarch64-only): aarch64_max_initfn(): >>>> >>>> The following comment in the code seems wrong to me: >>>> >>>> /* -cpu max: if KVM is enabled, like -cpu host (best possible with this host); */ >>>> >>>> This is not exactly true: >>>> >>>> "-cpu max" calls kvm_arm_set_cpu_features_from_host(), (which checks "dtb_compatible", and if not set gets the features from the host, if set ...?) >>>> After that, calls aarch64_add_sve_properties() and then adds also "svw-max-vq". This code is common with TCG. > > > As part of this research I noticed that arm_cpu_post_init() is quite confusing, seems really inconsistent to me. > > Apparently the intention was to call it from the leaf classes: > > commit 51e5ef459eca045d7e8afe880ee60190f0b75b26 > Author: Marc-André Lureau > Date: Tue Nov 27 12:55:59 2018 +0400 > > arm: replace instance_post_init() > > Replace arm_cpu_post_init() instance callback by calling it from leaf > classes, to avoid potential ordering issue with other post_init callbacks. > > Signed-off-by: Marc-André Lureau > Suggested-by: Igor Mammedov > Reviewed-by: Igor Mammedov > Acked-by: Eduardo Habkost > > > but then we end up calling it multiple times in the class hierarch, which is a recipe for bugs, and makes it difficult to understand what arm_cpu_post_init() > even means, what calling this function is supposed to do. > > For a "max" or "host" cpu on AArch64, this function is called: > > for the ARM CPU base class, TYPE_ARM_CPU, in > > cpu.c::arm_cpu_instance_init, > > then later again for the TYPE_AARCH64_CPU class, child of TYPE_ARM_CPU, in > > cpu64.c::aarch64_cpu_instance_init, > > then later again for the TYPE_ARM_HOST_CPU class, child of TYPE_AARCH64_CPU, in > > cpu.c::arm_host_initfn. > > Same for "max". > > When looking at 32bit CPUs instead, only the ARM CPU base class ends up calling arm_cpu_post_init. > "Leaf" classes do not do it (see cpu_tcg.c). > > What is then arm_cpu_post_init even supposed to mean? > > Thanks, > > Claudio > > >>>> >>>> In the case of cpu host instead, >>>> >>>> "-cpu host" calls kvm_arm_set_cpu_features_from_host(), same as max, then calls aarch64_add_sve_properties() but does NOT add "svw-max-vq". >>>> >>>> Is this a bug? >> >> It was left out intentionally. More below. >> >>> >>> Maybe; that's a question for Richard or Drew... >>> >>>> Are "max" and "host" for KVM supposed to be the same like with x86? >> >> Yes, but my understanding of "max" == "host" for KVM is that that only >> applies to the perspective of the guest. What CPU and what CPU features >> the guest can see should be exactly the same with either "max" or "host", >> depending on the enabling/disabling of any optional CPU properties. >> >> The question here seems to be that, if one has a CPU property, does that >> imply the other should have the same? Which would effectively allow the >> two to be aliases (when KVM is enabled). I don't know, does x86 ensure >> 100% property compatibility? >> >> I opted not to support sve-max-vq for "host" because I consider it a >> legacy CPU property, one I didn't want to propagate. Indeed it may >> make more sense to depreciate sve-max-vq than to "fix" this issue >> by adding it to "host". Note, we can already create equivalent SVE >> CPUs. The following are the same from the perspective of the guest >> >> -accel kvm -cpu host,sve512=on >> -accel kvm -cpu max,sve512=on >> >> And, for TCG, these are the same from the perspective of the guest >> >> -accel tcg -cpu max,sve512=on >> -accel tcg -cpu max,sve-max-vq=4 >> >> So we already don't need sve-max-vq. >> >> Thanks, >> drew >> > >