linux-kernel - Re: [PATCH 1/1] iommu/amd: Preserve default DTE fields when updating Host Page Table Root

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: <20250226163502.GC28425@nvidia.com>
Date: Wed, 26 Feb 2025 12:35:02 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Alejandro Jimenez <alejandro.j.jimenez@...cle.com>, joro@...tes.org
Cc: Vasant Hegde <vasant.hegde@....com>, dheerajkumar.srivastava@....com,
	sarunkod@....com, iommu@...ts.linux.dev,
	linux-kernel@...r.kernel.org, suravee.suthikulpanit@....com,
	will@...nel.org, joao.m.martins@...cle.com,
	boris.ostrovsky@...cle.com
Subject: Re: [PATCH 1/1] iommu/amd: Preserve default DTE fields when updating
 Host Page Table Root

On Wed, Feb 26, 2025 at 11:19:46AM -0500, Alejandro Jimenez wrote:
> On 1/7/25 13:01, Jason Gunthorpe wrote:
> > On Tue, Jan 07, 2025 at 05:45:38PM +0530, Vasant Hegde wrote:
> > > > @@ -2052,12 +2052,12 @@ static void set_dte_entry(struct amd_iommu *iommu,
> > > >   	make_clear_dte(dev_data, dte, &new);
> > > 
> > > This fix is fine. But with all changes we have done in this code does, do we
> > > really need make_clear_dte()?
> > 
> > > How about removing `make_clear_dte()` and moving DTE_FLAG_V to
> > > write_dte_lower128() ?
> > 
> > The V flag should just be set by the functions building the DTE,
> > write_dte_lower() should accept a fully formed dte as a matter of
> > layering.
> > 
> > I'm hopefull Suravee will come with something like this:
> > 
> > https://lore.kernel.org/linux-iommu/20241016142237.GP3559746@nvidia.com/
> > 
> 
> Suravee did say he would implement the suggestions above in the series for
> nested translation support, but that might take a while considering where
> we are in the cycle. Given that this fix is straightforward and has been
> reviewed by Dheeraj, are there any concerns with merging it in its current
> form?

+1 to take the fix

Jason