Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
Date:   Thu, 7 Dec 2023 09:38:25 -0400
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc:     Catalin Marinas <catalin.marinas@arm.com>,
        Marc Zyngier <maz@kernel.org>, ankita@nvidia.com,
        Shameerali Kolothum Thodi 
        <shameerali.kolothum.thodi@huawei.com>, oliver.upton@linux.dev,
        suzuki.poulose@arm.com, yuzenghui@huawei.com, will@kernel.org,
        ardb@kernel.org, akpm@linux-foundation.org, gshan@redhat.com,
        aniketa@nvidia.com, cjia@nvidia.com, kwankhede@nvidia.com,
        targupta@nvidia.com, vsethi@nvidia.com, acurrid@nvidia.com,
        apopple@nvidia.com, jhubbard@nvidia.com, danw@nvidia.com,
        mochs@nvidia.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
Message-ID: <20231207133825.GI2692119@nvidia.com>
References: <20231205164318.GG2692119@nvidia.com>
 <ZW949Tl3VmQfPk0L@arm.com>
 <20231205194822.GL2692119@nvidia.com>
 <ZXCJ3pVbKuHJ3LTz@arm.com>
 <20231206150556.GQ2692119@nvidia.com>
 <ZXCQrTbf6q0BIhSw@lpieralisi>
 <20231206153809.GS2692119@nvidia.com>
 <ZXCf_e-ACqrj6VrV@arm.com>
 <20231206164802.GT2692119@nvidia.com>
 <ZXGa4A6rfxLtkTB2@lpieralisi>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZXGa4A6rfxLtkTB2@lpieralisi>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?p2lInPG7+HvFJ/QV4Rl9Pvm7Y77r9O7E/I6Xf3z4jkELZr+qOxGlbQqqrYUf?=
 =?us-ascii?Q?qN/HoMOdLX2facLQDoFUJ2Bo7dGXSELZ9Elo8OPqvU1HYmxjfAS/fe6OMPEo?=
 =?us-ascii?Q?1MRHgF5aw7YNEax9dBHazay20Ei6LJq+I0zgsJFAuE2ESQNkYJhvTMTBAInV?=
 =?us-ascii?Q?KDMmww/FOR/lVNUR2fB7k3QS8ZktIiRKvTr6xxJgUh+9vmuPqqLXBqVrfYUN?=
 =?us-ascii?Q?NdGPFWRSDiBg9nZapq8gDIqvRV7IkHtwp33ejaH+g8NByk9euxZJf4gmqQmg?=
 =?us-ascii?Q?T+zxg5ChCvw5gBYJCXLBfWgXdArmQG3UIk7I1+ICYA5KlMkFGPBItpF30cEb?=
 =?us-ascii?Q?+86KovZeDxNE1BwPhMST54VLAeyXOCY3Vz7JHG8xRlynxHsINJQDN7wH7dpx?=
 =?us-ascii?Q?crCgkkL7rn81C7/chzxjQ/hMNz0oRQErYsG4bbNwRTs5fo7iN7L8VGyub/wp?=
 =?us-ascii?Q?3tM5yZUk5ZBE64Br+yonfAPYIPEsmpeuxPgdXLR8yerYcDj0UqhaYnTOXgtk?=
 =?us-ascii?Q?N5ImNumSTqtSdsrYXNrwf2YQ01FoCDPKxaajoQodFjtKzyzQ5p9wCIR9z9vo?=
 =?us-ascii?Q?j2M9T/+QiLF35nHRBzzi1zWn3FjF7Lmr5WE3yswGMFgoE4IPWDiVyQRIFu+O?=
 =?us-ascii?Q?uYIWn+r1GCK6CyD7eprlexPu9vnK+223UFzodwlkHHxViAbsBiu96J2nLYGP?=
 =?us-ascii?Q?CbIrPYzmmi0ptReY+8Wsaxz0preIsOwJRtfrRAw8NKNc0kHPWs3BqwkWcLxz?=
 =?us-ascii?Q?5AXVt+1xG99yZrdFgV6G+fbsXyP3PMkZMY6F/I8oLVGjMxcftE3p1x+K7iRN?=
 =?us-ascii?Q?l51byr1YABmErO06oT3huHy/ReFME6Wh6bl7Jiw1rDWCr0LUxZMDAD9XgPaX?=
 =?us-ascii?Q?1YGaotSuPWPVeHAO2oz7jvlU4UruUjtu1VbLZmCPSq5OkvjtEWm5YHTe0erS?=
 =?us-ascii?Q?VcPorsbEMJiBgmWzbgX1s+Zqz9GxlEkw+IfAAT2Na1oQybWd1xsRcRBbkeif?=
 =?us-ascii?Q?sLp5dsmmlYVvSYeLi7hWh+pvQ0ZrIl6/EedEIQA0ZcYJJpf9oiSk4ojB3RWC?=
 =?us-ascii?Q?ey0SWOvL1CHcJLW9V2dmigk1/t8BYmT3leVnAgzVYRDFes5MrsmOFdAYkB9F?=
 =?us-ascii?Q?ojibFeU1lir5DdfctevO/ZYxevXt0dRDivdRRiTD7okp9nD09qi2093eMKQ1?=
 =?us-ascii?Q?LG6M/u8RtCQaG1vN5g25HMeg2j7JT8NusM8hzcBwO7ZDZXFBbBrcIdHkP9rf?=
 =?us-ascii?Q?IEn2Ph5SCwcFneU7uAEpbNNCrbV2qB1t+QUZw7OBmJIhDITgP5+1xjiZDZXq?=
 =?us-ascii?Q?bbArTDONijhOFf3GvlvpbN5r/H9jOuHTnvkjEdO5K9iu2DZ0XAND5WyaaGXO?=
 =?us-ascii?Q?RCddAqhzS5SP4gJsXxyjyoZSWrUmJVOKJurhQs8SlrNxZSoZpDtDzJvXfnBx?=
 =?us-ascii?Q?bURMvRKkz1qBRvzL7aUGiIIRV8Ohz1BcciEftkC+D/wRG/Ir03sdNtl/2kjp?=
 =?us-ascii?Q?XZ4HmO65cOqTUKl5X5Ah0rdJmnyUYnAwPk9wBQToI7IeXbFb2CyB6Waid60I?=
 =?us-ascii?Q?Eo4S7T6CxLmsPtX69uakGzJWvMNCaVHVOcuRc+7H?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d83d53c0-7edb-445a-1e14-08dbf729c9f7
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2023 13:38:25.8836
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 3BvC8BnVt6ea0X/JCkPQw/WlLk6usmY0nQ6sEn+u20QWJ+uAlP6Jw9+VPKEYuDM2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB8289
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 07 Dec 2023 05:38:34 -0800 (PST)

On Thu, Dec 07, 2023 at 11:13:52AM +0100, Lorenzo Pieralisi wrote:
> > > What about the other way around - would we have a prefetchable BAR that
> > > has portions which are unprefetchable?
> > 
> > I would say possibly.
> > 
> > Prefetch is a dead concept in PCIe, it was obsoleted in PCI-X about 20
> > years ago. No PCIe system has ever done prefetch.
> > 
> > There is a strong incentive to mark BAR's as prefetchable because it
> > allows 64 bit addressing in configurations with bridges.
> 
> If by strong incentive you mean the "Additional guidance on the
> Prefetchable Bit in Memory Space BARs" in the PCI express specifications,
> I think it has been removed from the spec and the criteria that had to be
> met to implement it were basically impossible to fulfill on ARM systems,
> it did not make any sense in the first place.

No, I mean many systems don't have room to accommodate large 32 bit
BARs and the only real way to make stuff work is to have a 64 bit BAR
by setting prefetchable. Given mis-marking a read-side-effect region
as prefetchable has no actual consequence on PCI-E I would not be
surprised to learn people have done this.

> I agree on your statement related to the prefetchable concept but I
> believe that a prefetchable BAR containing regions that have
> read side-effects is essentially a borked design unless at system level
> speculative reads are prevented (as far as I understand the
> implementation note this could only be an endpoint integrated in a
> system where read speculation can't just happen (?)).

IMHO the PCIe concept of prefetchable has no intersection with the
CPU. The CPU chooses entirely on its own what rules to apply to the
PCI MMIO regions and no OS should drive that decision based on the
prefetchable BAR flag.

The *only* purpose of the prefetchable flag was to permit a classical
33/66MHz PCI bridge to prefetch reads because the physical bus
protocol back then did not include a read length.

For any system that does not have an ancient PCI bridge the indication
is totally useless.

Jason