Message-ID: <aaec67ab-0bb9-3c15-de81-97b92918c5c5@huawei.com>
Date:   Mon, 21 Jun 2021 13:08:51 +0100
From:   John Garry <john.garry@...wei.com>
To:     Robin Murphy <robin.murphy@....com>,
        Lu Baolu <baolu.lu@...ux.intel.com>,
        "joro@...tes.org" <joro@...tes.org>,
        "will@...nel.org" <will@...nel.org>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>,
        "corbet@....net" <corbet@....net>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        Linuxarm <linuxarm@...wei.com>,
        "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>,
        "chenxiang (M)" <chenxiang66@...ilicon.com>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        <nadav.amit@...il.com>
Subject: Re: [PATCH v14 6/6] iommu: Remove mode argument from
 iommu_set_dma_strict()

On 21/06/2021 12:59, Robin Murphy wrote:

+ Nadav

>> On a personal level I would be happy with that approach, but I think
>> it's better to not start changing things right away in a follow-up series.
>>
>> So how about we add this patch (which replaces 6/6 "iommu: Remove mode
>> argument from iommu_set_dma_strict()")?
>>
>> Robin, any opinion?
> For me it boils down to whether there are any realistic workloads where
> non-strict mode*would*  still perform better under virtualisation. The
> only reason for the user to explicitly pass "iommu.strict=0" is because
> they expect it to increase unmap performance; if it's only ever going to
> lead to an unexpected performance loss, I don't see any value in
> overriding the kernel's decision purely for the sake of subservience.
> 
> If there*are*  certain valid cases for allowing it for people who really
> know what they're doing, then we should arguably also log a counterpart
> message to say "we're honouring your override but beware it may have the
> opposite effect to what you expect" for the benefit of other users who
> assume it's a generic go-faster knob. At that point it starts getting
> non-trivial enough that I'd want to know for sure it's worthwhile.
> 
> The other reason this might be better to revisit later is that an AMD
> equivalent is still in flight[1], and there might be more that can
> eventually be factored out. I think both series are pretty much good to
> merge for 5.14, but time's already tight to sort out the conflicts which
> exist as-is, without making them any worse.

ok, fine. Can revisit.

As for getting these merged, I'll dry-run merging both of those series 
to see the conflicts. It doesn't look too problematic from a glance.

Cheers,
John

> 
> Robin.
> 
> [1]
> https://lore.kernel.org/linux-iommu/20210616100500.174507-3-namit@vmware.com/
> 
>> ------->8---------
>>
>> [PATCH] iommu/vt-d: Make "iommu.strict" override batching due to
>>    virtualization
>>
>> As a change in policy, make iommu.strict cmdline argument override
>> whether we disable batching due to virtualization.
>>
>> The API of iommu_set_dma_strict() is changed to accept a "force"
>> argument, which means that we always set iommu_dma_strict true,
>> regardless of whether we already set via cmdline. Also return a boolean,
>> to tell whether iommu_dma_strict was set or not.
>>
>> Note that in all pre-existing callsites of iommu_set_dma_strict(),
>> argument strict was true, so this argument is dropped.
>>
>> Signed-off-by: John Garry<john.garry@...wei.com>
>>
>> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
>> index 06666f9d8116..e8d65239b359 100644
>> --- a/drivers/iommu/intel/iommu.c
>> +++ b/drivers/iommu/intel/iommu.c
>> @@ -4380,10 +4380,8 @@ int __init intel_iommu_init(void)
>>             * is likely to be much lower than the overhead of synchronizing
>>             * the virtual and physical IOMMU page-tables.
>>             */
>> -        if (cap_caching_mode(iommu->cap)) {
>> +        if (cap_caching_mode(iommu->cap) && iommu_set_dma_strict(false))
>>                pr_info_once("IOMMU batching disallowed due to
>> virtualization\n");
>> -            iommu_set_dma_strict(true);
>> -        }
>>            iommu_device_sysfs_add(&iommu->iommu, NULL,
>>                           intel_iommu_groups,
>>                           "%s", iommu->name);
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index 60b1ec42e73b..1434bee64af3 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -349,10 +349,14 @@ static int __init iommu_dma_setup(char *str)
>>    }
>>    early_param("iommu.strict", iommu_dma_setup);
>>
>> -void iommu_set_dma_strict(bool strict)
>> +/* Return true if we set iommu_dma_strict */
>> +bool iommu_set_dma_strict(bool force)
>>    {
>> -    if (strict || !(iommu_cmd_line & IOMMU_CMD_LINE_STRICT))
>> -        iommu_dma_strict = strict;
>> +    if (force || !(iommu_cmd_line & IOMMU_CMD_LINE_STRICT)) {
>> +        iommu_dma_strict = true;
>> +        return true;
>> +    }
>> +    return false;
>>    }
>>
>>    bool iommu_get_dma_strict(struct iommu_domain *domain)
>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
>> index 32d448050bf7..f17b20234296 100644
>> --- a/include/linux/iommu.h
>> +++ b/include/linux/iommu.h
>> @@ -476,7 +476,7 @@ int iommu_enable_nesting(struct iommu_domain *domain);
>>    int iommu_set_pgtable_quirks(struct iommu_domain *domain,
>>            unsigned long quirks);
>>
>> -void iommu_set_dma_strict(bool val);
>> +bool iommu_set_dma_strict(bool force);
>>    bool iommu_get_dma_strict(struct iommu_domain *domain);
>>
>>    extern int report_iommu_fault(struct iommu_domain *domain, struct
>> device *dev,

Powered by blists - more mailing lists