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: <f95c6afb-0adc-47b8-b3da-b6c24b66cd8a@amd.com>
Date: Fri, 28 Feb 2025 15:24:49 +0530
From: Vasant Hegde <vasant.hegde@....com>
To: Alejandro Jimenez <alejandro.j.jimenez@...cle.com>,
 Jason Gunthorpe <jgg@...dia.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 2/26/2025 9:49 PM, 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?

Ack. I think its fine to pull current patch for now.

Reviewed-by: Vasant Hegde <vasant.hegde@....com>

-Vasant