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=-2.0 required=3.0 tests=BAYES_00,DATE_IN_PAST_03_06, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 E24B8C433ED for ; Fri, 23 Apr 2021 03:35:45 +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 0195261417 for ; Fri, 23 Apr 2021 03:35:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0195261417 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:38928 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lZmbX-0000U7-OW for qemu-devel@archiver.kernel.org; Thu, 22 Apr 2021 23:35:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39860) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZmai-0008Sb-Em; Thu, 22 Apr 2021 23:34:52 -0400 Received: from ozlabs.org ([203.11.71.1]:37197) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZmaf-0008CB-BV; Thu, 22 Apr 2021 23:34:52 -0400 Received: by ozlabs.org (Postfix, from userid 1007) id 4FRKfP187Nz9sW8; Fri, 23 Apr 2021 13:34:37 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1619148877; bh=0sI8ZWJJ2nNaO7OYaNNstU7K8C6z6Ey6r23/Q3Ncm/M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=f5HsXvk1MYF3y581qtRNJsVQyx/8aeO6hvgUNCTmM7py9pJ2Qe/+aKlNZZwqG7wh6 EAQmO53diBigkyxueEpOoo6Ly9+zjyQcYz6TXCM6/txaKwmdP9Fgm9MTVhWaHHYM1M OwWfZpotW2qa1HXS4PWSWIEtbQFLJMOmw3v/ygkM= Date: Fri, 23 Apr 2021 10:08:05 +1000 From: David Gibson To: Fabiano Rosas Subject: Re: [PATCH 1/4] target/ppc: Code motion required to build disabling tcg Message-ID: References: <87mttq15a1.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NeueufxrHXGRhabk" Content-Disposition: inline In-Reply-To: <87mttq15a1.fsf@linux.ibm.com> Received-SPF: pass client-ip=203.11.71.1; envelope-from=dgibson@ozlabs.org; helo=ozlabs.org X-Spam_score_int: -1 X-Spam_score: -0.2 X-Spam_bar: / X-Spam_report: (-0.2 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no 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: Thomas Huth , "qemu-devel@nongnu.org" , "lagarcia@br.ibm.com" , Lucas Mateus Martins Araujo e Castro , Fernando Eckhardt Valle , "qemu-ppc@nongnu.org" , Andre Fernando da Silva , Bruno Piazera Larsen , Matheus Kowalczuk Ferst , Luis Fernando Fujita Pires Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --NeueufxrHXGRhabk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 22, 2021 at 04:35:34PM -0300, Fabiano Rosas wrote: > Bruno Piazera Larsen writes: >=20 > >> > You are correct! I've just tweaked the code that defines spr_registe= r and > >> > it should be working now. I'm still working in splitting the SPR fun= ctions > >> > from translate_init, since I think it would make it easier to prepar= e the > >> > !TCG case and for adding new architectures in the future, and I foun= d a > >> > few more problems: > >> > >> Actually looking at the stuff below, I suspect that separating our > >> "spr" logic specifically might be a bad idea. At least some of the > >> SPRs control pretty fundamental things about how the processor > >> operates, and I suspect separating it from the main translation logic > >> may be more trouble than it's worth. >=20 > I disagree with the code proximity argument. Having TCG code clearly > separate from common code seems more important to me than having the SPR > callbacks close to the init_proc functions. Hmm.. I may be misinterpreting what you're intending here. I certainly agree that separating TCG only code from common code is a good idea. My point, though, is that the vast majority of the SPR code *is* TCG specific - there are just a relatively few cases where SPRs have a common path. That basically only happens when a) the SPR can be affected by means other than the guest executing instructions specifically to do that (i.e. usually by hypercalls) and b) accessing the SPR has some side effects that need to be handled in both TCG and KVM cases =46rom the descriptions it sounded like you were trying to separate *all* SPR code, not just these specific cases from the translation core, and that's what I'm saying is a bad idea. > But maybe we should take a look at this RFC before we start discussing > personal preference too much. >=20 > > Well, all the errors that I got were related to to read/write functions= , which > > I was already separating into a spr_tcg file. The solutions I can see a= re to > > include this file in translate.c, and either have the read/write functi= ons not be > > static, or include the spr_common.c in translate as well, but only for = TCG > > builds. Both solutions sound pretty bad imo, but the first sounds less = bad, > > because it's a bit less complexity in the build process. >=20 > It would be helpful if we could apply these patches and do some > experimentation before recommending a solution. So I would pick the less > bad for now. Mention it in the cover letter and then we can discuss > looking at something more concrete. >=20 --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --NeueufxrHXGRhabk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAmCCD+MACgkQbDjKyiDZ s5JUSxAAh8o1Kt6UEa4fXokGuOhWjTkCbjuTtVnhGg2wpk6CC9rdQocgaQY6FPhe ibEYqHBCqjdPYswtlZnqbuzh9q0xakRknQL9P8UxGwIML6w9IAlvhR/Hs8+y25EG kZ3AxZVYdpcjtWP4BjVPHFsyZXanm62JnKSTvPaNtJxsGmhFrsLZw/Y/HssmE1XU k5OE47Ne4UZ5PaF5K7KWGq8DhjXid6LT50EOeAWWKiEtjLr9cr1saV6goH1pjujW xbXJV8YPR6F5fhF79gYu45kvNOnc20sq4AMd9p9oCWZ86SPWf531ONGPp4HTqA2O 0Da7g8sjZ/qajSqUKW0uzMk0zqYBC5PiHnHqHrcdq8zqOtVD42FK23gBDEzcULkZ yCErSOqjOyjar3fLeH62btNRgcrYICGsH9PCyuUUqo1SGhU91NT6RnwtdpYolgMG slYTPI+8r3ZRsHYuRHH1Q3R8mFRvbBAyGNBncuFya9rMmZEaL2HrShoEqIZxuQTD CpincxvbcC9qYl2H3sAugJqp5gRcmhHLLtFNywTDuKvyjyY/dcJE2qS7JuPhB5PZ WDCoNkdFb/JcYUNZ9DNe1W/t36DjcCHK8ySuZzzr7jvIglTHBma0xP1+ggvTgU1q ZLTlCxq9u/q3QnzUny8xf1Ubj5majTXKlDX0xtZkX5YgHlZwWRc= =lee6 -----END PGP SIGNATURE----- --NeueufxrHXGRhabk--