From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5A87315B971 for ; Sun, 16 Aug 2026 12:50:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786884640; cv=none; b=Nfoey8H6aF7xsn+FJF/Adf3/94Vsyb7Ve8xp4S54d6pYyGiBpCtuFyagn+0ljzDRAB4I2Zg+vI2zPQFixlNWSXWlEj6QWtbxiO/2zPR9DDBSfjkRQShMaakdGqC5WglMpAXs4zV1vMZ99AiZ56s0U3TUGGGLd+sA1tjJZ2yUkhI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786884640; c=relaxed/simple; bh=/zJcq1dpAtnbiCH/k6eDkSCdhLNff6qFJqqgWbso61M=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=R6RoeKNoxmyAweRlwMSYZ1aa2fG98FlWnJVyAy/Vxapzk3jndh/AaU8aF2HH9h+wi5S37J+02JcTaxBxmkDhNuK7XrdLm++qWTZJIkYpajEgHq+4fLi8wX8okYqM0/uCVNcxsN/ofptP3UagY12tBSybi2RPQDZsx0/uyfGy63M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=reactivated.net; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.221.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=reactivated.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-47fde295992so1778348f8f.0 for ; Sun, 16 Aug 2026 05:50:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786884637; x=1787489437; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=sPrcGGvEf1e6P4d7hpsNvKZqUN+qMke5YpauuSzuEx4=; b=kPKK0sZOD4H30pXMu55tPuN6AYunI6CVmkj7Bq+iUz2Stj/kO+bpJFZwNL2PXuQMBY RVrAWQuySKWmBraOJ5jcJdIb654jOyARkvy0i+w6x4gP7OIvWmrfyJjnzQ75X/2a1n0v aEWCjlV38PEtCUmdHaC3C9VaWmZMgimFL0rmz4A536Ew7tE8llXxqGouGHwT0IZsAPCv NSGhcDibBzYknYvo1RF3yOUJmUcjU2ya610QngQgh3t4Z0mP43Uy/lA8PFK56SNSd4sk q0lNLK2X1F+H2zx4fbuw1ab9GS4mtjVnq17DhJtdXqI+nWuapjP/arDk3zrhg+0hhjXt KJRg== X-Forwarded-Encrypted: i=1; AHgh+RpxTMHpE2rXpMfrn5jrKey47dYy2dfQF0D0WSNxMTw+H/v3PKkpjF1LW/3fX3Mc51TJkj+SkGGPcMFR2K0=@vger.kernel.org X-Gm-Message-State: AOJu0Yzgb8KTWnoQhogT2ZJGdpyQm6JH1UDJ3RtCaqun8716hnjyzbAa waRbfDIAJEYql6ShmHeoOHQnBFNjwD2zmYTrRGWRWWnv9BY6pBuWqfVq X-Gm-Gg: AR+sD10e6gi372MdA8GRefuqQlb/3CvGWtWoCUX6cidCkuoNA7Tt2/OoKCzws4Ok1SK g5fk+05Vh4VrlMys99A3hZ0mNG6TFQGlUBsF0AYXbi55TXevg+ktGSDY99E3fl0K/lPCttj7B1m hTNHxQ0nqRSAZ4Fo2T5Tf2XHQJHSVviOXUMbM4nkJRWOlxw6NsuhryN2O/VIck+6GYA87mAgerS 896mt+Yr+wsrwh/YHW3nyplNJx5le0s15XDL78XUkftd9iXelofHezLvj2fR3F7BbjvSQiJvpGk lwRwkWlF2hoCYl0MRUotGdVm+ZBDsIG0+3OVOpGVhn5Tl+KMMOLo+/qWLDxSEtqbqhJia9tG268 T/kK6R5hYEoCsv0pq07MsZo8FbL2CK7zJu3zJqqHBGM91VNkohPGlTTdkTRTWZSAA9x+5i64y9I 6o90sObcH5DJWe3EbeyfT059I89WczpyojS5TFoObSDhSHPbB198UgAA4uHwFBdcmww+qxhtKmi uTfEhLsqri2a24oVFni5VQiFOvWAxa+GiUIEN/MqXWF/VwjlGnnHXbBTCE1Z+G+XwnsXBC+4zm9 AGs= X-Received: by 2002:a05:6000:184c:b0:481:314b:b041 with SMTP id ffacd0b85a97d-4816075f4f5mr30224247f8f.7.1786884636404; Sun, 16 Aug 2026 05:50:36 -0700 (PDT) Received: from ?IPV6:2001:8a0:d6cd:9000:86f4:4e71:9fc8:3183? ([2001:8a0:d6cd:9000:86f4:4e71:9fc8:3183]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4815f219e12sm22222287f8f.10.2026.08.16.05.50.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 16 Aug 2026 05:50:34 -0700 (PDT) Message-ID: Date: Sun, 16 Aug 2026 13:50:32 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/5] iommu: Add Broadcom BCM2712 IOMMU driver From: Daniel Drake To: Jason Gunthorpe , Robin Murphy Cc: "Joerg Roedel (AMD)" , Will Deacon , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Florian Fainelli , Broadcom internal kernel review list , iommu@lists.linux.dev, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, nick.hollinghurst@raspberrypi.com References: <20260727-bcm2712-iommu-submit-v2-0-0247b5c03de8@reactivated.net> <20260727-bcm2712-iommu-submit-v2-4-0247b5c03de8@reactivated.net> <3e7ba95b-51e7-48e4-aea5-f86db1739ac2@arm.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 31/07/2026 21:22, Daniel Drake wrote: > The aperture could be placed anywhere, but the key idea in the current > driver structure is that we deliberately place it above physical memory, > so that we can have the bypass window operational for all regular > physical addresses, meaning that iommu-unaware devices can operate as > normal. > > Each of the 3-4 IOMMUs has around 5 devices hardwired into it. When the > IOMMU is switched on (effectively via setting CTRL_OPERATING_FLAGS), > *all* of the hardwired devices are subject to the IOMMU operation, > uniformly. There is no gating where you can have one of the devices in > standard passthrough mode and the rest using the IOMMU. Also there is no > Stream ID in the transactions, there is no way to configure per-device > page tables. > > Among the devices hardwired to the IOMMUs we might have: >  - Devices already set up by the firmware and relying on regular access >    to physical memory >  - Devices that don't require large contiguous DMA allocations and would >    prefer not to have the translation overhead of the iommu >  - Devices that handle scatter-gather natively and prefer not to have >    the translation overhead of the iommu >  - & devices that want to use the IOMMU :) so that they can work with >    large contiguous allocations which are actually scattered in >    underlying physical memory > > So we have multiple needs to tend to, which is why the driver currently > sets up the bypass in the regular address space (serving the first 3 > above), and the IOMMU aperture in a high, unused part of the address > space (for the devices that do want to take advantage of the IOMMU). > > Are those good enough reasons to set up the driver in this way? Or are > there other approaches to consider? Reading the thread again I'm sensing that it would be preferred to go with a more conventional IOMMU setup, rather than trying to cover all of the above in a single configuration. For the next revision I am thinking: 1. Paging domain has the aperture at address 0, without bypass/identity region i.e. some degree of memory protection is present 2. Identity domain is complete iommu bypass (as-is) This allows the system admin to choose between the iommu benefits (and associated minor overhead) OR the non-iommu bypass mode. That choice would apply to all of the devices hardwired to the iommu in question -- we wouldn't attempt to support mixing identity and paging approaches at the same time as was originally proposed. Regarding devices set up by the firmware that require ongoing access to RAM, of which the display controller is probably the only case, we can use the existing mechanism that allows the firmware to communicate such requirements. The iommu driver will do: .get_resv_regions = iommu_dma_get_resv_regions, Then on the DT side, I would ask Raspberry Pi to provide a firmware adjustment in future versions. It already dynamically programs the framebuffer as a memreserve property, a hole in the memory map and as a simple-framebuffer node. We would need this additionally programmed as reserved-memory: reserved-memory { fw_fb: framebuffer@3f800000 { reg = <0x0 0x3f800000 0x0 0x800000>; iommu-addresses = <&vc4 0x0 0x3f800000 0x0 0x800000>; }; } and also a link back from vc4: vc4: gpu { memory-region = <&fw_fb>; }; This will cause the iommu driver to set up the initial page tables with the above memory region as an identity mapping. This is done before paging mode is activated, so once the iommu is actually switched on, the display controller will enjoy uninterrupted access to that framebuffer. Let me know if anything sounds off! Daniel