[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a37fa781-8372-5014-c96e-0dde43217778@arm.com>
Date: Mon, 14 Jun 2021 16:05:15 +0100
From: Robin Murphy <robin.murphy@....com>
To: John Garry <john.garry@...wei.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>
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>
Subject: Re: [PATCH v12 3/5] iommu/vt-d: Add support for IOMMU default DMA
mode build options
On 2021-06-14 15:19, John Garry wrote:
> On 14/06/2021 15:11, Robin Murphy wrote:
>> On 2021-06-14 08:53, John Garry wrote:
>>> On 12/06/2021 03:22, Lu Baolu wrote:
>>>> On 2021/6/11 20:20, John Garry wrote:
>>>>> @@ -453,8 +452,7 @@ static int __init intel_iommu_setup(char *str)
>>>>> pr_warn("intel_iommu=forcedac deprecated; use
>>>>> iommu.forcedac instead\n");
>>>>> iommu_dma_forcedac = true;
>>>>> } else if (!strncmp(str, "strict", 6)) {
>>>>> - pr_info("Disable batched IOTLB flush\n");
>>>>> - intel_iommu_strict = 1;
>>>>> + iommu_set_dma_strict(true);
>>>> I would like to deprecate this command line and ask users to use
>>>> iommu.strict instead.
>>> ok, but then I should probably make the AMD driver also officially
>>> support this.
>> Oops, I should have documented that "iommu.strict" already applies to
>> x86 as well. The interaction with the driver-specific parameters is a
>> bit weird and unintuitive, but it was done knowingly. Let me quickly
>> spin a kernel-parameters.txt fix for that...
>
> So I already had a pending patch here for the same to be included in
> this series:
> https://github.com/hisilicon/kernel-dev/commit/2375a2d888d78de9eb7d91d6f2c5891395300a96
>
>
> If you want to do it, then ok. I might have to reorder the series though...
Yeah, sorry for the complication. Your subsequent deprecation of the x86
parameters doesn't need to conflict, but we should probably also update
that the default value now depends on the kernel config, which will :(
Thanks,
Robin.
Powered by blists - more mailing lists