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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 3DB50C46CD2 for ; Tue, 9 Jan 2024 18:07:54 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rNGV9-000140-G1; Tue, 09 Jan 2024 13:06:59 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rNGV5-00013I-MJ; Tue, 09 Jan 2024 13:06:56 -0500 Received: from mail.ozlabs.org ([2404:9400:2221:ea00::3] helo=gandalf.ozlabs.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rNGUz-0002fE-J9; Tue, 09 Jan 2024 13:06:51 -0500 Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by gandalf.ozlabs.org (Postfix) with ESMTP id 4T8f5G0RL4z4wx8; Wed, 10 Jan 2024 05:06:42 +1100 (AEDT) Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4T8f561MDXz4wbR; Wed, 10 Jan 2024 05:06:33 +1100 (AEDT) Message-ID: Date: Tue, 9 Jan 2024 19:06:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 00/33] hw/cpu/arm: Remove one use of qemu_get_cpu() in A7/A15 MPCore priv Content-Language: en-US To: Fabiano Rosas , =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= , qemu-devel@nongnu.org, Juan Quintela Cc: Paolo Bonzini , Tyrone Ting , =?UTF-8?Q?Alex_Benn=C3=A9e?= , Manos Pitsidianakis , Eduardo Habkost , Joel Stanley , Alistair Francis , Anton Johansson , Andrey Smirnov , Peter Maydell , Hao Wu , Jean-Christophe Dubois , Igor Mitsyanko , "Edgar E. Iglesias" , Andrew Jeffery , Rob Herring , qemu-arm@nongnu.org, Mark Cave-Ayland , Peter Xu References: <20231212162935.42910-1-philmd@linaro.org> <03b969d3-1947-4186-b3ee-15e3cddc5f34@kaod.org> <18a38b88-8f20-420c-9916-a03d1b4930a7@linaro.org> <38cfa9de-874b-41dd-873e-5ad1f5a5805e@kaod.org> <87y1d6i47m.fsf@suse.de> <597186d9-af21-46e8-8075-f21d36c01c07@kaod.org> <87plya76cu.fsf@suse.de> From: =?UTF-8?Q?C=C3=A9dric_Le_Goater?= In-Reply-To: <87plya76cu.fsf@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2404:9400:2221:ea00::3; envelope-from=SRS0=Gpa9=IT=kaod.org=clg@ozlabs.org; helo=gandalf.ozlabs.org X-Spam_score_int: -39 X-Spam_score: -4.0 X-Spam_bar: ---- X-Spam_report: (-4.0 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On 1/9/24 18:40, Fabiano Rosas wrote: > Cédric Le Goater writes: > >> On 1/3/24 20:53, Fabiano Rosas wrote: >>> Philippe Mathieu-Daudé writes: >>> >>>> +Peter/Fabiano >>>> >>>> On 2/1/24 17:41, Cédric Le Goater wrote: >>>>> On 1/2/24 17:15, Philippe Mathieu-Daudé wrote: >>>>>> Hi Cédric, >>>>>> >>>>>> On 2/1/24 15:55, Cédric Le Goater wrote: >>>>>>> On 12/12/23 17:29, Philippe Mathieu-Daudé wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> When a MPCore cluster is used, the Cortex-A cores belong the the >>>>>>>> cluster container, not to the board/soc layer. This series move >>>>>>>> the creation of vCPUs to the MPCore private container. >>>>>>>> >>>>>>>> Doing so we consolidate the QOM model, moving common code in a >>>>>>>> central place (abstract MPCore parent). >>>>>>> >>>>>>> Changing the QOM hierarchy has an impact on the state of the machine >>>>>>> and some fixups are then required to maintain migration compatibility. >>>>>>> This can become a real headache for KVM machines like virt for which >>>>>>> migration compatibility is a feature, less for emulated ones. >>>>>> >>>>>> All changes are either moving properties (which are not migrated) >>>>>> or moving non-migrated QOM members (i.e. pointers of ARMCPU, which >>>>>> is still migrated elsewhere). So I don't see any obvious migration >>>>>> problem, but I might be missing something, so I Cc'ed Juan :> >>> >>> FWIW, I didn't spot anything problematic either. >>> >>> I've ran this through my migration compatibility series [1] and it >>> doesn't regress aarch64 migration from/to 8.2. The tests use '-M >>> virt -cpu max', so the cortex-a7 and cortex-a15 are not covered. I don't >>> think we even support migration of anything non-KVM on arm. >> >> it happens we do. >> > > Oh, sorry, I didn't mean TCG here. Probably meant to say something like > non-KVM-capable cpus, as in 32-bit. Nevermind. Theoretically, we should be able to migrate to a TCG guest. Well, this worked in the past for PPC. When I was doing more KVM related changes, this was very useful for dev. Also, some machines are partially emulated. Anyhow I agree this is not a strong requirement and we often break it. Let's focus on KVM only. >>> 1- https://gitlab.com/farosas/qemu/-/jobs/5853599533 >> >> yes it depends on the QOM hierarchy and virt seems immune to the changes. >> Good. >> >> However, changing the QOM topology clearly breaks migration compat, > > Well, "clearly" is relative =) You've mentioned pseries and aspeed > already, do you have a pointer to one of those cases were we broke > migration Regarding pseries, migration compat broke because of 5bc8d26de20c ("spapr: allocate the ICPState object from under sPAPRCPUCore") which is similar to the changes proposed by this series, it impacts the QOM hierarchy. Here is the workaround/fix from Greg : 46f7afa37096 ("spapr: fix migration of ICPState objects from/to older QEMU") which is quite an headache and this turned out to raise another problem some months ago ... :/ That's why I sent [1] to prepare removal of old machines and workarounds becoming a burden. Regarding aspeed, this series breaks compat. Not that we care much but ​this caught my attention because of my past experience on pseries. Same kind of QOM change which could impact other machines, like virt. Since you checked that migration compat is preserved on virt, we should be fine. Thanks, C. [1] https://lore.kernel.org/qemu-devel/20231214181723.1520854-1-clg@kaod.org/