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

[Vasant Hegde <vasant.hegde@amd.com>]

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