linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Wenjia Zhang <wenjia@linux.ibm.com>
Cc: Matthew Rosato <mjrosato@linux.ibm.com>,
	Gerd Bayer <gbayer@linux.ibm.com>,
	Pierre Morel <pmorel@linux.ibm.com>,
	iommu@lists.linux.dev, 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, linux-kernel@vger.kernel.org,
	Julian Ruess <julianr@linux.ibm.com>
Subject: Re: [PATCH v4 2/7] iommu: Allow .iotlb_sync_map to fail and handle s390's -ENOMEM return
Date: Thu, 19 Jan 2023 12:31:15 +0100	[thread overview]
Message-ID: <93d3397b1d0ec4e2ed24dfaccf4cafb0a9206907.camel@linux.ibm.com> (raw)
In-Reply-To: <20230104120543.308933-3-schnelle@linux.ibm.com>

On Wed, 2023-01-04 at 13:05 +0100, Niklas Schnelle wrote:
> On s390 when using a paging hypervisor, .iotlb_sync_map is used to sync
> mappings by letting the hypervisor inspect the synced IOVA range and
> updating a shadow table. This however means that .iotlb_sync_map can
> fail as the hypervisor may run out of resources while doing the sync.
> This can be due to the hypervisor being unable to pin guest pages, due
> to a limit on mapped addresses such as vfio_iommu_type1.dma_entry_limit
> or lack of other resources. Either way such a failure to sync a mapping
> should result in a DMA_MAPPING_ERROR.
> 
> Now especially when running with batched IOTLB flushes for unmap it may
> be that some IOVAs have already been invalidated but not yet synced via
> .iotlb_sync_map. Thus if the hypervisor indicates running out of
> resources, first do a global flush allowing the hypervisor to free
> resources associated with these mappings as well a retry creating the
> new mappings and only if that also fails report this error to callers.
> 
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> ---
> v3 -> v4:
> - Adapted signature of .iommu_tlb_sync mapo for sun50i IOMMU driver added in
>   v6.2-rc1 (kernel test robot)
> 
> 

@Joerg, this patch, while being a prerequisite to the DMA API
conversion, is independent and in fact would also be needed for IOMMU
use in a nested KVM guest. With Baolu's and Matt's R-b's I think it
would make sense to pick this up for v6.3 even if the DMA API
conversion takes longer while we figure out details and the flush queue
changes. What do you think?

Thanks,
Niklas

  parent reply	other threads:[~2023-01-19 11:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-04 12:05 [PATCH v4 0/7] iommu/dma: s390 DMA API conversion and optimized IOTLB flushing Niklas Schnelle
2023-01-04 12:05 ` [PATCH v4 1/7] s390/ism: Set DMA coherent mask Niklas Schnelle
2023-01-17 15:09   ` Matthew Rosato
2023-01-04 12:05 ` [PATCH v4 2/7] iommu: Allow .iotlb_sync_map to fail and handle s390's -ENOMEM return Niklas Schnelle
2023-01-05  7:15   ` Baolu Lu
2023-01-17 15:10   ` Matthew Rosato
2023-01-19 11:31   ` Niklas Schnelle [this message]
2023-01-04 12:05 ` [PATCH v4 3/7] s390/pci: prepare is_passed_through() for dma-iommu Niklas Schnelle
2023-01-17 15:10   ` Matthew Rosato
2023-01-04 12:05 ` [PATCH v4 4/7] s390/pci: Use dma-iommu layer Niklas Schnelle
2023-01-17 15:09   ` Matthew Rosato
2023-01-19 11:03     ` Niklas Schnelle
2023-01-19 15:59       ` Matthew Rosato
2023-01-19 16:04         ` Niklas Schnelle
2023-01-19 16:12           ` Matthew Rosato
2023-01-19 16:33     ` Niklas Schnelle
2023-01-19 16:40       ` Matthew Rosato
2023-01-04 12:05 ` [PATCH v4 5/7] iommu/dma: Allow a single FQ in addition to per-CPU FQs Niklas Schnelle
2023-01-19 15:55   ` Niklas Schnelle
2023-01-19 16:16     ` Niklas Schnelle
2023-01-04 12:05 ` [PATCH v4 6/7] iommu/dma: Enable variable queue size and use larger single queue Niklas Schnelle
2023-01-04 12:05 ` [PATCH v4 7/7] iommu/dma: Add IOMMU op to choose lazy domain type 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=93d3397b1d0ec4e2ed24dfaccf4cafb0a9206907.camel@linux.ibm.com \
    --to=schnelle@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=gbayer@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=julianr@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mjrosato@linux.ibm.com \
    --cc=pmorel@linux.ibm.com \
    --cc=robin.murphy@arm.com \
    --cc=svens@linux.ibm.com \
    --cc=wenjia@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;
as well as URLs for NNTP newsgroup(s).