Re: [PATCH v1] iommu/vt-d: Remove the redundant logic in first_level_by_default()

[Ethan Zhao <haifeng.zhao@linux.intel.com>]

在 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@intel.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"