lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9018994f-de55-41b3-ae45-59cccaaf8603@tecnico.ulisboa.pt>
Date: Mon, 16 Jun 2025 11:23:37 +0100
From: Diogo Ivo <diogo.ivo@...nico.ulisboa.pt>
To: Mikko Perttunen <cyndis@...si.fi>,
 Thierry Reding <thierry.reding@...il.com>
Cc: Mikko Perttunen <mperttunen@...dia.com>, David Airlie
 <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Jonathan Hunter <jonathanh@...dia.com>,
 Philipp Zabel <p.zabel@...gutronix.de>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, linux-kernel@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, linux-tegra@...r.kernel.org,
 devicetree@...r.kernel.org
Subject: Re: [PATCH 0/3] NVIDIA Tegra210 NVJPG support



On 6/12/25 2:55 AM, Mikko Perttunen wrote:
> On 6/12/25 12:06 AM, Thierry Reding wrote:
>> On Wed, Jun 11, 2025 at 01:05:40PM +0100, Diogo Ivo wrote:
>>> I have a question here, what exactly are the stream IDs? While working
>>> on the driver this came up and I didn't manage to figure it out.
>>
>> Stream IDs are a way to identify memory transactions as belonging to a
>> certain device. This comes into play when working with the IOMMU (which
>> is a Tegra SMMU on Tegra210 and earlier, and an ARM SMMU on Tegra) and
>> is used to isolate DMA capable devices. Basically for every stream ID
>> you get a separate I/O address space. NVJPG will have its own address
>> space, and so will VIC. Each device can only access whatever has been
>> mapped to it's I/O address space. That means NVJPG can't interfere with
>> VIC and vice-versa. And neither can any of these engines read from or
>> write to random system memory if badly programmed.
>>
>> For Tegra SMMU there's no such thing as programmable stream IDs, so the
>> stream ID is fixed for the given device.
>>
>> On newer chips (Tegra186 and later, or maybe it wasn't until Tegra194),
> 
> Tegra186 and newer -- all chips with the ARM SMMU. To add a little bit, 
> each engine can address two stream IDs, one for firmware and one for 
> data. All user specified buffers are mapped into the data IOMMU domain, 
> and these are switched between jobs / applications.
> 
> As an aside, currently each engine has its own firmware stream ID, but 
> that's a bit wasteful, since the kernel allocates a separate IOMMU 
> domain for each. The firmwares are all read-only so they could be in a 
> shared one. We've had to consolidate these on some platforms that ran 
> out of IOMMU domains otherwise. Not really a concern with upstream 
> platforms, though.

Does this dual Stream ID also apply to Tegra210?

> Also need to program the THI_STREAMID / TRANSCFG registers during boot.

Thanks,
Diogo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ