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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9DC3AC433EF for ; Tue, 9 Nov 2021 22:56:19 +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 3A817610C8 for ; Tue, 9 Nov 2021 22:56:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3A817610C8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=nuviainc.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:38342 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mka2M-0003IF-6c for qemu-devel@archiver.kernel.org; Tue, 09 Nov 2021 17:56:18 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33394) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mkZzD-0000fR-5G for qemu-devel@nongnu.org; Tue, 09 Nov 2021 17:53:03 -0500 Received: from [2a00:1450:4864:20::42b] (port=38502 helo=mail-wr1-x42b.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mkZz7-0008HO-AK for qemu-devel@nongnu.org; Tue, 09 Nov 2021 17:52:59 -0500 Received: by mail-wr1-x42b.google.com with SMTP id u18so610164wrg.5 for ; Tue, 09 Nov 2021 14:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=+xLp7dacCBCy4620NVyS91oE2zwQj4tmo1glBUi4mHY=; b=hINUKwbFhTFX4U5ayjIkuuIF5nWOtKuQBHi2vmjNQGcCMQsO4NzF47TYA0vy8RWBBn SegD0L8jYLlDB5V9FXDJurgFGA8YPvhsjzxu1AbP5IgQeigMpMN9qscZxTq59wmAQxkj Waeoj3pywydgXgbU4uJUYLQZuILwe13ol7iYtJpBYzIGTnE30EYE+ZbBdwNi06+m2/+x uXigLU1UUeN1ESyZiPBiqEmV0g6BMR4QArB5e47wU+xHNQl0HHH5jK08zNh9sIZ/o9Yj e0E4GPMSA5ASmva3L73EHgwNeoqpOrz6ngsxQjFKM1N65RtcxdQNhEdgRf087kMCXTFD ZkBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=+xLp7dacCBCy4620NVyS91oE2zwQj4tmo1glBUi4mHY=; b=GPN2BvlbqPdnSwX7bLAYAjP79bKg/DupZW0f8wrbYbwUJo4mD2zbOfJ+Lv1WD2PY8j 5pZcWI2deKKpe1ISqVhC+uly3rtvKo3JhYqnUqnDh81u0bE/7qiCi9dPfunJo9xBilYY 6VPAcynkFrjMU3EGEJMtjntVNgs04nufFB6DjgedkPFTZbX2+vH/J3xzHmShmzrNcpbn 6a/tGdlxvYQyc6ywTxu/O32ekwhXkaotdLSsYtw/LzLIdHRdb9RNrme+pRSFh+RrcDqW 0HvKJi6XfILwmgO95J7lQ7mHdAEOd9t5XxIiI74SbEAUY9//eH0SsmOxkfY+e0VLccE4 m8rQ== X-Gm-Message-State: AOAM531FNYEl3uZK48GBaXbDLkX/qm99KOYJoJS534aJLdYK7O/iT/WH vDiq2dq7xJtlcB1MV5Ws84R3sw== X-Google-Smtp-Source: ABdhPJz0wCoPAnFy8NcRn69idxtU95iybhRMj66V/MpwJ0sKaa1Zdw4qaru4WTntviC59LWWkoDTqg== X-Received: by 2002:adf:8008:: with SMTP id 8mr13554790wrk.188.1636498374289; Tue, 09 Nov 2021 14:52:54 -0800 (PST) Received: from leviathan (cpc92314-cmbg19-2-0-cust559.5-4.cable.virginm.net. [82.11.186.48]) by smtp.gmail.com with ESMTPSA id d6sm20859488wrx.60.2021.11.09.14.52.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Nov 2021 14:52:53 -0800 (PST) Date: Tue, 9 Nov 2021 22:52:51 +0000 From: Leif Lindholm To: Peter Maydell Subject: Re: [PATCH v8 07/10] hw/arm/sbsa-ref: add ITS support in SBSA GIC Message-ID: <20211109225251.gfr2mvm3jynvdsnk@leviathan> References: <20210812165341.40784-1-shashi.mallela@linaro.org> <20210812165341.40784-8-shashi.mallela@linaro.org> <20210902124258.mqjhx7lqqvkczf6a@leviathan> <20211015122351.vc55mwzjbevl6wjy@leviathan> <20211109204249.usvfatm3frar3u7a@leviathan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::42b (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::42b; envelope-from=leif@nuviainc.com; helo=mail-wr1-x42b.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=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.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marcin Juszkiewicz , "Michael S. Tsirkin" , Shashi Mallela , Radoslaw Biernacki , QEMU Developers , narmstrong@baylibre.com, Eric Auger , qemu-arm , Igor Mammedov , Alex =?utf-8?Q?Benn=C3=A9e?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, Nov 09, 2021 at 21:21:46 +0000, Peter Maydell wrote: > > Hmm, right. So you're thinking containing the versioning fully in the > > interfaces presented by the model: > > - Is the version node present? > > - If so, is it greater than X? > > - If so, is it great enough to support the SCP interface? > > And let the firmware deal with that? > > How the model tells the firmware about the presence/absence of > certain things and whether it's one version or another is > a different question again :-) I guess since we're using DTB > already for passing some info to the firmware that that would be > the way to continue. Whether it's better to have a simple > "version" node or property, or to have perhaps distinct things > in the DTB to indicate presence/absence of important features I > don't know and leave up to you. Right. So my preference is to communicate the version only, and then have that version let firmware know whether there are now other interfaces available (i.e. an SCP) to gather additional system information. > > I was kind of thinking it was expected for incompatible machine > > versions to be qemu versioned. But I'm good with skipping that bit if > > it's not. > > The other thing we should nail down is how the user is going to > select which flavour of machine they want to provide. Three > options: > (1) no control, QEMU just emulates whatever the newest flavour is. > User needs to go find a firmware image new enough to cope. > (2) different flavours exposed as different machine types > (analogous to how we have musca-a and musca-b1, or raspi3ap and > raspi3b, for instance). Old user command lines keep working > because -M sbsa-ref doesn't change; the new stuff would be > available via -M sbsa-ref-2 or whatever. > (3) different flavours exposed via a property > (so you would have -M sbsa-ref,machine-revision=2 or something). > If the revision defaults to 1 then old user setups still work > but everybody starts to have to cart around an extra command > line argument. If it defaults to "newest we know about" you > get the opposite set of tradeoffs. I'm leaning towards (1), at least while working towards a "complete" platform (when we may still add/change features, but not how those features are communicated to the firmware). Once the platform is complete, I would very much want to support (3), for example to tweak GIC layout to match GIC-600 or GIC-700, with different configurations. / Leif