From: Jason Gunthorpe <jgg@nvidia.com>
To: Niklas Schnelle <schnelle@linux.ibm.com>
Cc: Matthew Rosato <mjrosato@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, joro@8bytes.org, will@kernel.org,
robin.murphy@arm.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/5] iommu/s390: Fix duplicate domain attachments
Date: Thu, 6 Oct 2022 09:02:21 -0300 [thread overview]
Message-ID: <Yz7Dzayee74Mu4NH@nvidia.com> (raw)
In-Reply-To: <8c01ad419e91c0ce06bec8700d960c57f1a7c436.camel@linux.ibm.com>
On Thu, Oct 06, 2022 at 01:52:44PM +0200, Niklas Schnelle wrote:
> One option I see would be to ignore the error return from
> zpci_register_ioat() if it indicates case 2b. Then we would still add
> the device to the IOMMU's devices list and return success despite
> knowing that the device is inaccessible (DMA and MMIO blocked).
>
> Then the recovery/reset code will register the new domain once the
> device comes out of the error state. At least from an IOMMU API point
> of view that would make the attachment always succeed for all
> zpci_register_ioat() error cases that aren't programming bugs and can
> conceivably be recovered from.
This is what I was thinking..
> If you agree I would propose adding this as a robustness improvement as
> part of my upcoming series of IOMMU improvements needed for the DMA API
> conversion. As stated above before the DMA API conversion any error
> that would cause zpci_register_ioat() to fail while the IOMMU API is
> being used will need a "power cycle" anyway so postponing this doesn't
> hurt.
Yes, I think this series is fine as is
Patch 4 mostly deletes all these error cases, and the one hunk that is left:
+ if (domain->geometry.aperture_start > zdev->end_dma ||
+ domain->geometry.aperture_end < zdev->start_dma)
+ return -EINVAL;
Is misplaced. If a device cannot be supported by the IOMMU, which is
what that is really saying since it only s390 creates one aperture
size, then it should fail to probe, not fail at attach.
So I'd change the above to a WARN_ON() for future safety and add a
similar test to probe and then all that is left is the
zpci_register_ioat() which you have a plan for.
Jason
next prev parent reply other threads:[~2022-10-06 12:02 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 [this message]
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
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=Yz7Dzayee74Mu4NH@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