From: Eric Farman <farman@linux.ibm.com>
To: Matthew Rosato <mjrosato@linux.ibm.com>, qemu-s390x@nongnu.org
Cc: pmorel@linux.ibm.com, schnelle@linux.ibm.com, cohuck@redhat.com,
thuth@redhat.com, pasic@linux.ibm.com, borntraeger@linux.ibm.com,
richard.henderson@linaro.org, david@redhat.com,
qemu-devel@nongnu.org
Subject: Re: [PATCH 1/3] s390x/pci: RPCIT second pass when mappings exhausted
Date: Fri, 04 Nov 2022 11:50:04 -0400 [thread overview]
Message-ID: <fb2201af4be59910309686fb821d6cb9bcadf437.camel@linux.ibm.com> (raw)
In-Reply-To: <20221028194758.204007-2-mjrosato@linux.ibm.com>
On Fri, 2022-10-28 at 15:47 -0400, Matthew Rosato wrote:
> If we encounter a new mapping while the number of available DMA
> entries
> in vfio is 0, we are currently skipping that mapping which is a
> problem
> if we manage to free up DMA space after that within the same RPCIT --
> we will return to the guest with CC0 and have not mapped everything
> within the specified range. This issue was uncovered while testing
> changes to the s390 linux kernel iommu/dma code, where a different
> usage pattern was employed (new mappings start at the end of the
> aperture and work back towards the front, making us far more likely
> to encounter new mappings before invalidated mappings during a
> global refresh).
>
> Fix this by tracking whether any mappings were skipped due to vfio
> DMA limit hitting 0; when this occurs, we still continue the range
> and unmap/map anything we can - then we must re-run the range again
> to pickup anything that was missed. This must occur in a loop until
> all requests are satisfied (success) or we detect that we are still
> unable to complete all mappings (return ZPCI_RPCIT_ST_INSUFF_RES).
>
> Link:
> https://lore.kernel.org/linux-s390/20221019144435.369902-1-schnelle@linux.ibm.com/
> Fixes: 37fa32de70 ("s390x/pci: Honor DMA limits set by vfio")
> Reported-by: Niklas Schnelle <schnelle@linux.ibm.com>
> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
> ---
> hw/s390x/s390-pci-inst.c | 29 ++++++++++++++++++++++-------
> 1 file changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
> index 20a9bcc7af..7cc4bcf850 100644
> --- a/hw/s390x/s390-pci-inst.c
> +++ b/hw/s390x/s390-pci-inst.c
> @@ -677,8 +677,9 @@ int rpcit_service_call(S390CPU *cpu, uint8_t r1,
> uint8_t r2, uintptr_t ra)
> S390PCIBusDevice *pbdev;
> S390PCIIOMMU *iommu;
> S390IOTLBEntry entry;
> - hwaddr start, end;
> + hwaddr start, end, sstart;
> uint32_t dma_avail;
> + bool again;
>
> if (env->psw.mask & PSW_MASK_PSTATE) {
> s390_program_interrupt(env, PGM_PRIVILEGED, ra);
> @@ -691,7 +692,7 @@ int rpcit_service_call(S390CPU *cpu, uint8_t r1,
> uint8_t r2, uintptr_t ra)
> }
>
> fh = env->regs[r1] >> 32;
> - start = env->regs[r2];
> + sstart = start = env->regs[r2];
> end = start + env->regs[r2 + 1];
>
> pbdev = s390_pci_find_dev_by_fh(s390_get_phb(), fh);
> @@ -732,6 +733,9 @@ int rpcit_service_call(S390CPU *cpu, uint8_t r1,
> uint8_t r2, uintptr_t ra)
> goto err;
> }
>
> + retry:
> + start = sstart;
> + again = false;
> while (start < end) {
> error = s390_guest_io_table_walk(iommu->g_iota, start,
> &entry);
> if (error) {
> @@ -739,13 +743,24 @@ int rpcit_service_call(S390CPU *cpu, uint8_t
> r1, uint8_t r2, uintptr_t ra)
> }
>
> start += entry.len;
> - while (entry.iova < start && entry.iova < end &&
> - (dma_avail > 0 || entry.perm == IOMMU_NONE)) {
> - dma_avail = s390_pci_update_iotlb(iommu, &entry);
> - entry.iova += TARGET_PAGE_SIZE;
> - entry.translated_addr += TARGET_PAGE_SIZE;
> + while (entry.iova < start && entry.iova < end) {
> + if (dma_avail > 0 || entry.perm == IOMMU_NONE) {
> + dma_avail = s390_pci_update_iotlb(iommu, &entry);
> + entry.iova += TARGET_PAGE_SIZE;
> + entry.translated_addr += TARGET_PAGE_SIZE;
> + } else {
> + /*
> + * We are unable to make a new mapping at this time,
> continue
> + * on and hopefully free up more space. Then
> attempt another
> + * pass.
> + */
> + again = true;
> + break;
> + }
> }
> }
> + if (again && dma_avail > 0)
> + goto retry;
> err:
> if (error) {
> pbdev->state = ZPCI_FS_ERROR;
next prev parent reply other threads:[~2022-11-04 15:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-28 19:47 [PATCH 0/3] s390x/pci: rpcit fixes and enhancements Matthew Rosato
2022-10-28 19:47 ` [PATCH 1/3] s390x/pci: RPCIT second pass when mappings exhausted Matthew Rosato
2022-11-04 15:50 ` Eric Farman [this message]
2022-10-28 19:47 ` [PATCH 2/3] s390x/pci: coalesce unmap operations Matthew Rosato
2022-11-04 16:01 ` Eric Farman
2022-10-28 19:47 ` [PATCH 3/3] s390x/pci: shrink DMA aperture to be bound by vfio DMA limit Matthew Rosato
2022-11-04 16:08 ` Eric Farman
2022-12-12 8:37 ` [PATCH 0/3] s390x/pci: rpcit fixes and enhancements Thomas Huth
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=fb2201af4be59910309686fb821d6cb9bcadf437.camel@linux.ibm.com \
--to=farman@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=pmorel@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=schnelle@linux.ibm.com \
--cc=thuth@redhat.com \
/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).