[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5b09afe0-54c6-4f70-8748-c49918005b7d@siemens.com>
Date: Tue, 27 Aug 2024 15:38:04 +0200
From: Jan Kiszka <jan.kiszka@...mens.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Nishanth Menon <nm@...com>, Santosh Shilimkar <ssantosh@...nel.org>,
Vignesh Raghavendra <vigneshr@...com>, Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, Siddharth Vadapalli <s-vadapalli@...com>,
Bao Cheng Su <baocheng.su@...mens.com>, Hua Qian Li
<huaqian.li@...mens.com>, Diogo Ivo <diogo.ivo@...mens.com>,
Bjorn Helgaas <bhelgaas@...gle.com>, Krzysztof WilczyĆski
<kw@...ux.com>, linux-pci@...r.kernel.org,
Lorenzo Pieralisi <lpieralisi@...nel.org>
Subject: Re: [PATCH 0/5] soc: ti: Add and use PVU on K3-AM65 for DMA isolation
On 27.08.24 14:44, Krzysztof Kozlowski wrote:
> On 27/08/2024 11:22, Jan Kiszka wrote:
>> On 27.08.24 08:35, Krzysztof Kozlowski wrote:
>>> On 26/08/2024 21:25, Jan Kiszka wrote:
>>>> On 26.08.24 20:53, Krzysztof Kozlowski wrote:
>>>>> On 26/08/2024 19:56, Jan Kiszka wrote:
>>>>>> Only few of the K3 SoCs have an IOMMU and, thus, can isolate the system
>>>>>> against DMA-based attacks of external PCI devices. The AM65 is without
>>>>>> an IOMMU, but it comes with something close to it: the Peripheral
>>>>>> Virtualization Unit (PVU).
>>>>>>
>>>>>> The PVU was originally designed to establish static compartments via a
>>>>>> hypervisor, isolate those DMA-wise against each other and the host and
>>>>>> even allow remapping of guest-physical addresses. But it only provides
>>>>>> a static translation region, not page-granular mappings. Thus, it cannot
>>>>>> be handled transparently like an IOMMU.
>>>>>
>>>>> You keep developing on some old kernel. I noticed it on few patchsets
>>>>> last days. Please work on mainline.
>>>>>
>>>>
>>>> How did you come to this conclusion? This patch set was written for
>>>> mainline, just rebased and tested again over next-20240826 before
>>>> sending today.
>>>
>>> You send it to addresses you CANNOT get from mainline kernel. There is
>>> no way mainline kernel get_maintainers.pl produces them.
>>>
>>
>> That is likely due to that I didn't re-run the get_maintainers.pl for
>> all areas of changes but rather reused an address list from a slightly
>> older posting, sorry.
>>
>> IOW, your assumption is still not correct when it comes to code.
>
> Sure, I see results and I am guessing the reason. Keeping the list
> static is not the approach you should be using, as seen here. It does
> not make even sense, because then you need to keep several lists per
> different subsystems or you CC unrelated people (don't). Just use simple
> wrapper over git send email, b4 or patman.
>
> https://github.com/krzk/tools/blob/master/linux/.bash_aliases_linux#L91
> ha
Those options are useful, unconditional automated usage of the script is
not when you might be targeting multiple subsystems in a series (not
that uncommon in our scenarios). That's why shaping/confirming the final
list remains a manual step for me. But I'll improve on keeping it updated.
Thanks,
Jan
--
Siemens AG, Technology
Linux Expert Center
Powered by blists - more mailing lists