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] [day] [month] [year] [list]

Message-ID: <oxaboinp6alkzsutgwa3szea4exw2ipnfowxjyspcwt55qnkri@x6bwklyqzoil>
Date: Fri, 30 May 2025 04:32:13 +0000
From: Ankit Soni <Ankit.Soni@....com>
To: Vasant Hegde <vasant.hegde@....com>
CC: Joao Martins <joao.m.martins@...cle.com>, <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

On Wed, May 28, 2025 at 05:49:35PM +0530, Vasant Hegde wrote:
> 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
> 
> 

Sure vasant, thanks for confirming. I'll post v3 soon with this change.
Thanks,
-Ankit