From: Matthew Rosato <mjrosato@linux.ibm.com>
To: Niklas Schnelle <schnelle@linux.ibm.com>,
joro@8bytes.org, will@kernel.org, robin.murphy@arm.com,
gerald.schaefer@linux.ibm.com
Cc: hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com,
svens@linux.ibm.com, borntraeger@linux.ibm.com,
farman@linux.ibm.com, clegoate@redhat.com, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH v3 3/3] iommu/s390: implement iommu passthrough via identity domain
Date: Wed, 5 Feb 2025 14:55:45 -0500 [thread overview]
Message-ID: <c0c82eb4-3849-4127-b6bf-bee329653a24@linux.ibm.com> (raw)
In-Reply-To: <53c930df7058288776392073964a70025ca62d19.camel@linux.ibm.com>
On 1/30/25 2:43 AM, Niklas Schnelle wrote:
> On Fri, 2025-01-24 at 15:17 -0500, Matthew Rosato wrote:
>> Enabled via the kernel command-line 'iommu.passthrough=1' option.
>>
>> Introduce the concept of identity domains to s390-iommu, which relies on
>> the bus_dma_region to offset identity mappings to the start of the DMA
>> aperture advertized by CLP.
>>
>> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
>> ---
>> arch/s390/pci/pci.c | 6 ++-
>> drivers/iommu/s390-iommu.c | 95 +++++++++++++++++++++++++++++---------
>> 2 files changed, 76 insertions(+), 25 deletions(-)
>>
>> diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
>> index 88f72745fa59..758b23331754 100644
>> --- a/arch/s390/pci/pci.c
>> +++ b/arch/s390/pci/pci.c
>> @@ -124,14 +124,16 @@ int zpci_register_ioat(struct zpci_dev *zdev, u8 dmaas,
>> struct zpci_fib fib = {0};
>> u8 cc;
>>
>> - WARN_ON_ONCE(iota & 0x3fff);
>> fib.pba = base;
>> /* Work around off by one in ISM virt device */
>> if (zdev->pft == PCI_FUNC_TYPE_ISM && limit > base)
>> fib.pal = limit + (1 << 12);
>> else
>> fib.pal = limit;
>> - fib.iota = iota | ZPCI_IOTA_RTTO_FLAG;
>> + if (iota == 0)
>> + fib.iota = iota;
>
> Taking another look, I think there is a small problem with the logic of
> passing iota == 0 to indicate direct mapping. In
> zpci_hot_reset_device() we call zpci_register_ioat() with iota set to
> virt_to_phys(zdev->dma_table) and while zdev->dma_table is NULL for the
> identity domain we can't rely on virt_to_phys(NULL) == NULL.
Thanks for pointing this out. We discussed this a fair bit off-list, but to summarize here: I'll include an additional patch in the next version that will drive IOAT registration code through s390-iommu, since really this owns the dma_table and knows when it does (not) make sense to register it. Places in s390 code that need to perform IOAT re-registration (such as zpci_hot_reset_device) will call into this routine and let s390-iommu determine the correct action based upon the type of domain in use.
I'll set that patch before this one, so then this patch remains unchanged except to replace the zpci_register_ioat call added by this patch in s390_attach_dev_identity with the new routine.
>
>> + else
>> + fib.iota = iota | ZPCI_IOTA_RTTO_FLAG;
>> fib.gd = zdev->gisa;
>> cc = zpci_mod_fc(req, &fib, status);
>> if (cc)
prev parent reply other threads:[~2025-02-05 19:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-24 20:17 [PATCH v3 0/3] iommu/s390: add support for IOMMU passthrough Matthew Rosato
2025-01-24 20:17 ` [PATCH v3 1/3] s390/pci: check for relaxed translation capability Matthew Rosato
2025-01-29 10:07 ` Niklas Schnelle
2025-01-24 20:17 ` [PATCH v3 2/3] s390/pci: store DMA offset in bus_dma_region Matthew Rosato
2025-01-29 10:20 ` Niklas Schnelle
2025-01-24 20:17 ` [PATCH v3 3/3] iommu/s390: implement iommu passthrough via identity domain Matthew Rosato
2025-01-28 17:30 ` Jason Gunthorpe
2025-01-29 10:29 ` Niklas Schnelle
2025-01-30 7:43 ` Niklas Schnelle
2025-02-05 19:55 ` Matthew Rosato [this message]
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=c0c82eb4-3849-4127-b6bf-bee329653a24@linux.ibm.com \
--to=mjrosato@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=clegoate@redhat.com \
--cc=farman@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=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