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

Message-ID: <b3ed5d5e-4b9d-445e-8d2b-3b315322ff2e@oracle.com>
Date: Wed, 26 Feb 2025 11:19:46 -0500
From: Alejandro Jimenez <alejandro.j.jimenez@...cle.com>
To: Jason Gunthorpe <jgg@...dia.com>, Vasant Hegde <vasant.hegde@....com>,
        dheerajkumar.srivastava@....com, sarunkod@....com
Cc: iommu@...ts.linux.dev, linux-kernel@...r.kernel.org, joro@...tes.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 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?

Otherwise I can implement and test the more extensive changes that Jason
provided above, and hopefully Suravee's work on nested support can easily
merge with those once ready.

Alejandro