[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <g3xrnjfs6zekogfohud2s7kdvphx43e6mdh3vfpllynrwokxwf@vvetz2j2nrai>
Date: Fri, 25 Apr 2025 16:25:40 +0000
From: Ankit Soni <Ankit.Soni@....com>
To: 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 Joao,
Thank you for review this patch.
On Thu, Apr 24, 2025 at 01:19:43PM +0100, Joao Martins wrote:
> > {
> > + if (amd_iommu_hatdis)
> > + return false;
> > +
> > return iommu && (iommu->features & FEATURE_HDSUP);
> > }
> >
>
> It's strange we seem to somehow have host translation disabled, while it
> advertises other translation-related features like the normal case.
If HATDis bit is enabled driver will ignore host(v1) page table related field,
this includes nested page table.
>
> In any case we should probably follow Intel's example (which does similar thing
> to HATSDis) where we only call invoke IOMMU groups
> iommu_device_register()/iommu_device_sysfs_add() with DMA translation enabled?
> That should simplify most of the patch as those codepaths are not reachable via
> kernel/userspace? Unless I am missing something ofc
>
> See also commit c40aaaac10 ("iommu/vt-d: Gracefully handle DMAR units with no
> supported address widths"). I am not sure what else is the closest example here
> besides intel-iommu equivalent.
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.
Thanks,
-Ankit
Powered by blists - more mailing lists