public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Matthew Rosato <mjrosato@linux.ibm.com>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	Pierre Morel <pmorel@linux.ibm.com>,
	iommu@lists.linux.dev
Cc: linux-s390@vger.kernel.org, borntraeger@linux.ibm.com,
	hca@linux.ibm.com, gor@linux.ibm.com,
	gerald.schaefer@linux.ibm.com, agordeev@linux.ibm.com,
	svens@linux.ibm.com, joro@8bytes.org, will@kernel.org,
	jgg@nvidia.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 5/5] iommu/s390: Fix incorrect pgsize_bitmap
Date: Tue, 4 Oct 2022 16:31:38 +0100	[thread overview]
Message-ID: <a02a3cee-773a-da00-616f-04652c0905ce@arm.com> (raw)
In-Reply-To: <b3c6fd2b-74d4-91d7-dc53-ba526c41b067@linux.ibm.com>

On 2022-10-04 16:12, Matthew Rosato wrote:
> On 10/4/22 11:02 AM, Robin Murphy wrote:
>> On 2022-10-04 13:07, Niklas Schnelle wrote:
>>> The .pgsize_bitmap property of struct iommu_ops is not a page mask but
>>> rather has a bit set for each size of pages the IOMMU supports. As the
>>> comment correctly pointed out at this moment the code only support 4K
>>> pages so simply use SZ_4K here.
>>
>> Unless it's already been done somewhere else, you'll want to switch over to the {map,unmap}_pages() interfaces as well to avoid taking a hit on efficiency here. The "page mask" thing was an old hack to trick the core API into making fewer map/unmap calls where the driver could map arbitrary numbers of pages at once anyway. The multi-page interfaces now do that more honestly and generally better (since they work for non-power-of-two sizes as well).
> 
> Thanks for the heads up -- Niklas has some additional series coming soon as described here:
> 
> https://lore.kernel.org/linux-iommu/a10424adbe01a0fd40372cbd0736d11e517951a1.camel@linux.ibm.com/
> 
> So implementing the _pages() interfaces is soon up on the roadmap.  But given what you say I wonder if this patch should just wait until the series that implements {map,unmap}_pages().

Perhaps, although the full change should be trivial enough that there's 
probably just as much argument for doing the whole thing in its own 
right for the sake of this cleanup. The main point is that 
S390_IOMMU_PGSIZES is not incorrect as such, it's just not spelling out 
the deliberate trick that it's achieving - everyone copied it from 
intel-iommu, but since that got converted to the new interfaces the 
original explanation is now gone. The only effect of "fixing" it in 
isolation right now will be to make large VFIO mappings slower.

Robin.

>>> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
>>> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
>>> ---
>>>    drivers/iommu/s390-iommu.c | 9 +--------
>>>    1 file changed, 1 insertion(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/iommu/s390-iommu.c b/drivers/iommu/s390-iommu.c
>>> index 94c444b909bd..6bf23e7830a2 100644
>>> --- a/drivers/iommu/s390-iommu.c
>>> +++ b/drivers/iommu/s390-iommu.c
>>> @@ -12,13 +12,6 @@
>>>    #include <linux/sizes.h>
>>>    #include <asm/pci_dma.h>
>>>    -/*
>>> - * Physically contiguous memory regions can be mapped with 4 KiB alignment,
>>> - * we allow all page sizes that are an order of 4KiB (no special large page
>>> - * support so far).
>>> - */
>>> -#define S390_IOMMU_PGSIZES    (~0xFFFUL)
>>> -
>>>    static const struct iommu_ops s390_iommu_ops;
>>>      struct s390_domain {
>>> @@ -350,7 +343,7 @@ static const struct iommu_ops s390_iommu_ops = {
>>>        .probe_device = s390_iommu_probe_device,
>>>        .release_device = s390_iommu_release_device,
>>>        .device_group = generic_device_group,
>>> -    .pgsize_bitmap = S390_IOMMU_PGSIZES,
>>> +    .pgsize_bitmap = SZ_4K,
>>>        .get_resv_regions = s390_iommu_get_resv_regions,
>>>        .default_domain_ops = &(const struct iommu_domain_ops) {
>>>            .attach_dev    = s390_iommu_attach_device,
> 

  reply	other threads:[~2022-10-04 15:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-04 12:07 [PATCH v4 0/5] iommu/s390: Fixes related to attach and aperture handling Niklas Schnelle
2022-10-04 12:07 ` [PATCH v4 1/5] iommu/s390: Fix duplicate domain attachments Niklas Schnelle
2022-10-04 12:43   ` Jason Gunthorpe
2022-10-04 16:18   ` Matthew Rosato
2022-10-05  7:58     ` Niklas Schnelle
2022-10-05 11:48       ` Jason Gunthorpe
2022-10-06 11:52         ` Niklas Schnelle
2022-10-06 12:02           ` Jason Gunthorpe
2022-10-06 13:01             ` Niklas Schnelle
2022-10-04 12:07 ` [PATCH v4 2/5] iommu/s390: Get rid of s390_domain_device Niklas Schnelle
2022-10-04 16:20   ` Matthew Rosato
2022-10-04 12:07 ` [PATCH v4 3/5] iommu/s390: Fix potential s390_domain aperture shrinking Niklas Schnelle
2022-10-04 21:12   ` Matthew Rosato
2022-10-04 12:07 ` [PATCH v4 4/5] iommu/s390: Fix incorrect aperture check Niklas Schnelle
2022-10-04 12:07 ` [PATCH v4 5/5] iommu/s390: Fix incorrect pgsize_bitmap Niklas Schnelle
2022-10-04 14:38   ` Matthew Rosato
2022-10-04 15:02   ` Robin Murphy
2022-10-04 15:12     ` Matthew Rosato
2022-10-04 15:31       ` Robin Murphy [this message]
2022-10-04 16:13         ` Niklas Schnelle
2022-10-05  9:53           ` Robin Murphy
2022-10-05 11:03             ` Niklas Schnelle

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=a02a3cee-773a-da00-616f-04652c0905ce@arm.com \
    --to=robin.murphy@arm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mjrosato@linux.ibm.com \
    --cc=pmorel@linux.ibm.com \
    --cc=schnelle@linux.ibm.com \
    --cc=svens@linux.ibm.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