linux-kernel - Re: [PATCH 1/2] iommu/amd: Add HATDis feature support

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: <3b38fc9d-83c6-4db8-8a83-eb4265796b03@amd.com>
Date: Wed, 28 May 2025 17:49:35 +0530
From: Vasant Hegde <vasant.hegde@....com>
To: Ankit Soni <Ankit.Soni@....com>, Joao Martins <joao.m.martins@...cle.com>
Cc: iommu@...ts.linux.dev, suravee.suthikulpanit@....com, joro@...tes.org,
 will@...nel.org, robin.murphy@....com, linux-kernel@...r.kernel.org,
 Alejandro Jimenez <alejandro.j.jimenez@...cle.com>,
 David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 1/2] iommu/amd: Add HATDis feature support

Hi Ankit,


On 5/12/2025 12:00 PM, Ankit Soni wrote:
> Hi,
> 
> On Thu, May 08, 2025 at 06:03:44PM +0100, Joao Martins wrote:
>> On 06/05/2025 06:12, Ankit Soni wrote:
>>> On Wed, Apr 30, 2025 at 12:41:04PM +0100, Joao Martins wrote:
>>>>> With intel patch you mentioned above, it seems that it is mostly handling 
>>>>> "second stage translation support" disable, which will eventually disable dma 
>>>>> translation. And in AMD case, HATDis bit indicates host(v1) translation is not
>>>>> available, then attempt to use guest(v2) translation, and if both page
>>>>> table modes are not available then disable dma tranlation.
>>>>
>>>> OK, I guess it makes sense if HATDis is v1 only.
>>>>
>>>> My other call out was that when we disable dma-translation all together (aka
>>>> both modes), then we shouldn't advertise the IOMMU groups (internally and to
>>>> userspace) by not calling iommu_device_register()/iommu_device_sysfs_add().
>>>>
>>>
>>> Sorry for the late reply. I had cross-checked it; if the probe fails,
>>> then IOMMU groups will not be populated, and eventually, it will not
>>> have significance for calling iommu_device_register()/iommu_device_sysfs_add().
>>>
>>
>> It would nonetheless populate a ivhd entry in sysfs needlessly but with an empty
>> devices list (qemu diff at the tail end for how I checked it; it's only missing
>> the ILLEGAL_DEVICE_TABLE_ENTRY event being generated, but enough to check the
>> first patch with sw iommu) e.g. as far as I checked:
>>
>> $ find /sys | grep ivhd
>> /sys/class/iommu/ivhd0
>> /sys/devices/pci0000:00/0000:00:05.0/iommu/ivhd0
>> /sys/devices/pci0000:00/0000:00:05.0/iommu/ivhd0/uevent
>> /sys/devices/pci0000:00/0000:00:05.0/iommu/ivhd0/amd-iommu
>> /sys/devices/pci0000:00/0000:00:05.0/iommu/ivhd0/amd-iommu/cap
>> /sys/devices/pci0000:00/0000:00:05.0/iommu/ivhd0/amd-iommu/features
>> /sys/devices/pci0000:00/0000:00:05.0/iommu/ivhd0/devices
>> /sys/devices/pci0000:00/0000:00:05.0/iommu/ivhd0/device
>> /sys/devices/pci0000:00/0000:00:05.0/iommu/ivhd0/subsystem
>>
> 
> I was assuming, since iommu is still active for interrupt remapping,
> user may need info for cap and feature using /sys fs.
> @vasant: can you please suggest on this?

I don't have strong preference. But it looks like intel skips populating sysfs
properties. May be we can match the behaviour and skip populating ivdh entries.

-Vasant