From: Jason Gunthorpe <jgg@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Niklas Schnelle <schnelle@linux.ibm.com>,
Pierre Morel <pmorel@linux.ibm.com>,
Matthew Rosato <mjrosato@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, joro@8bytes.org, will@kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/2] iommu/s390: Fix race with release_device ops
Date: Thu, 1 Sep 2022 11:34:55 -0300 [thread overview]
Message-ID: <YxDDD2DF9KFDQ+Yk@nvidia.com> (raw)
In-Reply-To: <3e402947-61f9-b7e8-1414-fde006257b6f@arm.com>
On Thu, Sep 01, 2022 at 03:29:16PM +0100, Robin Murphy wrote:
> Right, the next step would be to bridge that gap to iommu-dma to dump the
> flush queue when IOVA allocation failure implies we've reached the
> "rollover" point, and perhaps not use the timer at all. By that point a
> dedicated domain type, or at least some definite internal flag, for this
> alternate behaviour seems like the logical way to go.
At least on this direction, I've been thinking it would be nice to
replace the domain type _FQ with a flag inside the domain, maybe the
ops, saying how the domain wants the common DMA API to operate. If it
wants FQ mode or other tuning parameters
Jason
next prev parent reply other threads:[~2022-09-01 14:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-31 20:12 [PATCH v4 0/2] iommu/s390: fixes related to repeat attach_dev calls Matthew Rosato
2022-08-31 20:12 ` [PATCH v4 1/2] iommu/s390: Fix race with release_device ops Matthew Rosato
2022-09-01 7:56 ` Pierre Morel
2022-09-01 9:37 ` Niklas Schnelle
2022-09-01 11:01 ` Robin Murphy
2022-09-01 13:42 ` Niklas Schnelle
2022-09-01 14:17 ` Niklas Schnelle
2022-09-01 14:29 ` Robin Murphy
2022-09-01 14:34 ` Jason Gunthorpe [this message]
2022-09-01 15:03 ` Robin Murphy
2022-09-01 15:49 ` Jason Gunthorpe
2022-09-01 17:00 ` Robin Murphy
2022-09-01 20:28 ` Matthew Rosato
2022-09-02 7:49 ` Niklas Schnelle
2022-09-01 10:25 ` Robin Murphy
2022-09-01 16:14 ` Matthew Rosato
2022-09-01 20:37 ` Jason Gunthorpe
2022-09-02 17:11 ` Matthew Rosato
2022-09-02 17:21 ` Jason Gunthorpe
2022-09-02 18:20 ` Matthew Rosato
2022-09-05 9:46 ` Robin Murphy
2022-09-06 13:36 ` Jason Gunthorpe
2022-09-02 10:48 ` Robin Murphy
2022-08-31 20:12 ` [PATCH v4 2/2] iommu/s390: fix leak of s390_domain_device Matthew Rosato
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=YxDDD2DF9KFDQ+Yk@nvidia.com \
--to=jgg@nvidia.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=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=robin.murphy@arm.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