Message-ID: <420178e9-ff55-4c22-b52e-da5af72d096c@linaro.org>
Date: Tue, 27 Aug 2024 15:43:12 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Jan Kiszka <jan.kiszka@...mens.com>, 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/2024 15:38, Jan Kiszka wrote:
> 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.

For that use git send-email identity hack. And anyway it still does not
apply to patchset here which should have been sent to everyone or SPLIT.
Putting DTS in the middle is a no-go, because it suggests there is
depednency and you CANNOT have such dependency.

Best regards,
Krzysztof

Powered by blists - more mailing lists