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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 36E8EC43214 for ; Thu, 2 Sep 2021 13:14:44 +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 E55DE610A0 for ; Thu, 2 Sep 2021 13:14:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E55DE610A0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:36820 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mLmYF-0005rV-3y for qemu-devel@archiver.kernel.org; Thu, 02 Sep 2021 09:14:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38504) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLmCY-0002oB-MC for qemu-devel@nongnu.org; Thu, 02 Sep 2021 08:52:18 -0400 Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]:42871) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mLmCW-0007df-Ub for qemu-devel@nongnu.org; Thu, 02 Sep 2021 08:52:18 -0400 Received: by mail-wr1-x42c.google.com with SMTP id q11so2743243wrr.9 for ; Thu, 02 Sep 2021 05:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lYNmEGkIuFx6TjJSX+P6lLIIW6Ug3xJdcY/Vmj7fk5Q=; b=j9/+L7kt/r5BwbJCJUxsrFb2ll/Cf83FDNDq06t4CJbw1tNKuhIpQepoEaqxF81L9P /mLf7bdKXvN3cBIhswvZsFSRr9ZjrQ2g9xBXdxYfTdDAQFWvTbJ0/CbuoJbT4P9C2wAW GQzaLI0TA3mTCqnwrKSTq4JYP4EF/btJmcJgWP61jN1NMROheD3xOLFhglDUOc1FhREh T4bX2WtChc1/c8n/kHQC5T/ek4wFR7P3H7UCamkZwcRnJZb8WVVBP1OGLj6t73xt4lt+ /6nuMlQzCJtyb76lxcn0Qdw3B7hhrqmmG14jBalE5mrvby78eiMxFg5Fo7j+j7/s6PTl 3tAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lYNmEGkIuFx6TjJSX+P6lLIIW6Ug3xJdcY/Vmj7fk5Q=; b=LVgsCBbREB/VqxIyvvzw9UIt/XPSXdJBegRBPU0pjiXZZZF2J69mKYgu+JAo8BfUcC klcuVJt/RXiyIRlBWFSI6rcOyogw9PEtOAc2SpArXPiwig/STJ+nOg1pCR24rAoYaQUE GP9G+0Q/rGJ/6/kQsBzWvnbuDvlFhrB1HZbBcqG671OiI7FxQx7+gBnhHHeLglvcuWNC 4TkFD9VZ/k8xyr6K1Yvk5EcZwc2oYRdYVDQk8aSnlgYhAV33xxlj/FNEf0gT+TBcGHun KSNSv+wmSDtKwBL0xLdTRfybMg33HCbys4Ng74Q4w/RXS7vgcKrWnh8gsDnqz8+qR+XA NuZg== X-Gm-Message-State: AOAM533pD1xPLNwzG/sn0bb0R0VD3agS+sLyVDZZsf8Kn4EkBu/N2yNY 2jWBqqzuNOtghqmsXuO24bwtHr+OqSPxm8marP8tZg== X-Google-Smtp-Source: ABdhPJyu8fQZGxsp7XGM1iDn+hYFCoBKnDrIgCj+XJEd/0P1JSyVmLEhb1L8K7Gkx1qiUbq9TwwxPjHgouMkO0JOdWI= X-Received: by 2002:adf:ba0f:: with SMTP id o15mr3539200wrg.386.1630587134332; Thu, 02 Sep 2021 05:52:14 -0700 (PDT) MIME-Version: 1.0 References: <20210812165341.40784-1-shashi.mallela@linaro.org> <20210812165341.40784-8-shashi.mallela@linaro.org> <20210902124258.mqjhx7lqqvkczf6a@leviathan> In-Reply-To: <20210902124258.mqjhx7lqqvkczf6a@leviathan> From: Peter Maydell Date: Thu, 2 Sep 2021 13:51:26 +0100 Message-ID: Subject: Re: [PATCH v8 07/10] hw/arm/sbsa-ref: add ITS support in SBSA GIC To: Leif Lindholm Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::42c; envelope-from=peter.maydell@linaro.org; helo=mail-wr1-x42c.google.com 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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: "Michael S. Tsirkin" , Shashi Mallela , Radoslaw Biernacki , QEMU Developers , narmstrong@baylibre.com, Eric Auger , qemu-arm , Igor Mammedov Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, 2 Sept 2021 at 13:43, Leif Lindholm wrote: > On Thu, Aug 19, 2021 at 14:27:19 +0100, Peter Maydell wrote: > > If you want a command line switch to let the user say whether the > > ITS should be present or not, you should use the same thing the > > virt board does, which is a bool property "its". > > > > If you want the sbsa-ref board to become a proper "versioned machine > > type" such that users can say "-M sbsa-ref-6.1" and get the SBSA > > board exactly as QEMU 6.1 supplied it, that looks completely different > > (and is a heavy back-compatibility burden, so needs discussion about > > whether now is the right time to do it), and probably is better not > > tangled up with this patchseries. > > Hmm. I mean, you're absolutely right about the complexity and need for > discussion. My concern is that we cannot insert the ITS block in the > memory map where it would be in an ARM GIC implementation without > changing the memory map (pushing the redistributor further down). > > It is also true that simply versioning sbsa-ref does not mean we end > up with a properly aligned with ARM IP register frame layout. Some > additional logic is required for that. > > If we assume that we don't want to further complicate this set by > adding the additional logic *now*, I see three options: > - Implement memory map versioning for sbsa-ref for this set, placing > the ITS (if enabled) directly after the DIST for sbsa-ref-6.2. > - In this set, place the ITS frames in a different location relative > to the REDIST frames than it will end up once the further logic is > implemented. > - Drop the sbsa-ref ITS support from this set, and bring it in with > the set implementing the additional logic. I don't think implementing versioned machine types helps you much anyway, because your users are all going to be currently using -M sbsa-ref, so they will by default see the change in device layout. I do think that we should get the "with an ITS" device layout right from the start, so that we're only dealing with 2 possibilities (what we have today, and the final intended layout), not 3 (today, final layout, some intermediate thing). How does guest software on this board figure out the memory layout ? Is there a mechanism for telling it "this is version 2 of this board" ? -- PMM