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: <01e5d0a9-715a-48d4-a2a4-2a0b5d99149b@linux.intel.com>
Date: Thu, 29 May 2025 13:48:03 +0800
From: Ethan Zhao <haifeng.zhao@...ux.intel.com>
To: Wei Wang <wei.w.wang@...el.com>, baolu.lu@...ux.intel.com,
 kevin.tian@...el.com, yi.l.liu@...el.com, dwmw2@...radead.org,
 jroedel@...e.de, linux-kernel@...r.kernel.org, iommu@...ts.linux.dev
Subject: Re: [PATCH v1] iommu/vt-d: Remove the redundant logic in
 first_level_by_default()


在 2025/5/23 16:10, Wei Wang 写道:
> This original implementation included redundant logic to determine whether
> first-stage translation should be used by default. Simplify it and
> preserve the original behavior:
> - Returns false in legacy mode (no scalable mode support).
> - Defaults to first-level translation when both FLTS and SLTS are
>    supported.
>
> Signed-off-by: Wei Wang <wei.w.wang@...el.com>
> ---
>   drivers/iommu/intel/iommu.c | 10 +---------
>   1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index cb0b993bebb4..228da47ab7cd 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -1366,15 +1366,7 @@ static void free_dmar_iommu(struct intel_iommu *iommu)
>    */
>   static bool first_level_by_default(struct intel_iommu *iommu)
>   {
> -	/* Only SL is available in legacy mode */
> -	if (!sm_supported(iommu))
> -		return false;
> -
> -	/* Only level (either FL or SL) is available, just use it */
> -	if (ecap_flts(iommu->ecap) ^ ecap_slts(iommu->ecap))
> -		return ecap_flts(iommu->ecap);
> -
> -	return true;

The function works like a digital circurt has 3 single bit inputs  sm, 
flts, slts and one bit output ret.

so the true value table of the orignal function looks like

    sm   flts   slts    ret
a   0     x     x      false
b   1     1     0      true
c   1     0     1      false
d   1     1     1      true
e   1     0     0      true

> +	return sm_supported(iommu) && ecap_flts(iommu->ecap);

And the true value table of this new one looks like

    sm  flts slts    ret

f   1     1     x      true
g   1     0     x      false

h   0     1     x      false
i    0     0     x      false

h, i covers a
g,   doesn't cover e, c
f,   covers b, d

So if we take them as two circurt blocks (chip), their functions aren't 
equal to each other.

If we don't make any assumption,  I wouldn't replace the old chip with 
new one

But, maybe all the new chip and old one all works well under specific 
context that I

didn't think deeper. :)



Thanks,

Ethan

>   }
>   
>   int domain_attach_iommu(struct dmar_domain *domain, struct intel_iommu *iommu)

-- 
"firm, enduring, strong, and long-lived"


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ