mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: Robin Murphy <robin.murphy@arm.com>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"will@kernel.org" <will@kernel.org>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	"corbet@lwn.net" <corbet@lwn.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	Linuxarm <linuxarm@huawei.com>,
	"Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>,
	"chenxiang (M)" <chenxiang66@hisilicon.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	<nadav.amit@gmail.com>
Subject: Re: [PATCH v14 6/6] iommu: Remove mode argument from iommu_set_dma_strict()
Date: Mon, 21 Jun 2021 13:08:51 +0100	[thread overview]
Message-ID: <aaec67ab-0bb9-3c15-de81-97b92918c5c5@huawei.com> (raw)
In-Reply-To: <2330bb52-1768-5122-9378-7923034c82bd@arm.com>

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@huawei.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,


  reply	other threads:[~2021-06-21 12:15 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-18 11:34 [PATCH v14 0/6] iommu: Enhance IOMMU default DMA mode build options John Garry
2021-06-18 11:34 ` [PATCH v14 1/6] iommu: Deprecate Intel and AMD cmdline methods to enable strict mode John Garry
2021-06-18 13:09   ` Lu Baolu
2021-06-18 11:34 ` [PATCH v14 2/6] iommu: Print strict or lazy mode at init time John Garry
2021-06-18 13:10   ` Lu Baolu
2021-06-18 11:34 ` [PATCH v14 3/6] iommu: Enhance IOMMU default DMA mode build options John Garry
2021-06-18 13:11   ` Lu Baolu
2021-06-18 11:34 ` [PATCH v14 4/6] iommu/vt-d: Add support for " John Garry
2021-06-18 13:12   ` Lu Baolu
2021-06-18 11:34 ` [PATCH v14 5/6] iommu/amd: " John Garry
2021-06-18 11:34 ` [PATCH v14 6/6] iommu: Remove mode argument from iommu_set_dma_strict() John Garry
2021-06-18 13:13   ` Lu Baolu
2021-06-21  5:17   ` Lu Baolu
2021-06-21  8:12     ` John Garry
2021-06-21 10:00       ` Lu Baolu
2021-06-21 10:34         ` John Garry
2021-06-21 11:59           ` Robin Murphy
2021-06-21 12:08             ` John Garry [this message]
2021-06-21 14:32             ` Lu Baolu
2021-06-22 22:25               ` Robin Murphy
2021-06-23  7:21                 ` Lu Baolu
2021-06-25 16:41 ` [PATCH v14 0/6] iommu: Enhance IOMMU default DMA mode build options John Garry
2021-07-08  9:38   ` joro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aaec67ab-0bb9-3c15-de81-97b92918c5c5@huawei.com \
    --to=john.garry@huawei.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=chenxiang66@hisilicon.com \
    --cc=corbet@lwn.net \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=nadav.amit@gmail.com \
    --cc=robin.murphy@arm.com \
    --cc=thunder.leizhen@huawei.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®