public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Niklas Schnelle <schnelle@linux.ibm.com>
Cc: Matthew Rosato <mjrosato@linux.ibm.com>,
	linux-s390@vger.kernel.org, alex.williamson@redhat.com,
	cohuck@redhat.com, farman@linux.ibm.com, pmorel@linux.ibm.com,
	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, frankja@linux.ibm.com, david@redhat.com,
	imbrenda@linux.ibm.com, vneethv@linux.ibm.com,
	oberpar@linux.ibm.com, freude@linux.ibm.com, thuth@redhat.com,
	pasic@linux.ibm.com, Robin Murphy <robin.murphy@arm.com>
Subject: Re: s390-iommu.c default domain conversion
Date: Fri, 20 May 2022 13:43:05 -0300	[thread overview]
Message-ID: <20220520164305.GK1343366@nvidia.com> (raw)
In-Reply-To: <dd2d49bb798effaeac55f4bf3625f376bb1abda0.camel@linux.ibm.com>

On Fri, May 20, 2022 at 06:26:03PM +0200, Niklas Schnelle wrote:
> > So, from what I can tell, the S390 HW is not really the same as a
> > normal iommu in that you can do map over IOVA that hasn't been flushed
> > yet and the map will restore coherency to the new page table
> > entries. I see the zpci_refresh_trans() call in map which is why I
> > assume this?
> 
> The zpci_refresh_trans() in map is only there because previously we
> didn't implement iotlb_sync_map(). Also, we only need to flush on map
> for the paged guest case so the hypervisor can update its shadow table.
> It happens unconditionally in the existing s390_iommu.c because that
> was not well optimized and uses the same s390_iommu_update_trans() for
> map and unmap. We had the skipping of the TLB flush handled properly in
> the arch/s390/pci_dma.c mapping code where !zdev->tlb_refresh indicates
> that we don't need flushes on map.

Even the arch/s390/pci_dma.c has a zpci_refresh_trans() on map, it is
just conditional on zdev->tlb_refresh

I had also assumed that the paging case uses this path?

> > (note that normal HW has a HW IOTLB cache that MUST be flushed or new
> > maps will not be loaded by the HW, so mapping to areas that previously
> > had uninvalidated IOVA is a functional problem, which motivates the
> > design of this scheme)
> 
> We do need to flush the TLBs on unmap. The reason is that under LPAR
> (non paging hypervisor) the hardware can establish a new mapping on its
> own if an I/O PTE is changed from invalid to a valid translation and it
> wasn't previously in the TLB. I think that's how most hardware IOMMUs
> work and how I understand your explanation too.

Since you said LPAR was OK performance wise, I was thinking only about
the paging case.

You can have different iommu_domains implementations for these two
cases.

But if the paging case doesn't need the hypercall anyhow it doesn't
work.

You'd have to change the core code to increase the timer duration, I
think.

Jason

      reply	other threads:[~2022-05-20 16:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-09 23:35 s390-iommu.c default domain conversion Jason Gunthorpe
2022-05-10 15:25 ` Matthew Rosato
2022-05-10 16:09   ` Jason Gunthorpe
2022-05-20 13:05     ` Niklas Schnelle
2022-05-20 13:44       ` Jason Gunthorpe
2022-05-20 15:17         ` Niklas Schnelle
2022-05-20 15:51           ` Robin Murphy
2022-05-20 15:56           ` Jason Gunthorpe
2022-05-20 16:26             ` Niklas Schnelle
2022-05-20 16:43               ` Jason Gunthorpe [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=20220520164305.GK1343366@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=agordeev@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=mjrosato@linux.ibm.com \
    --cc=oberpar@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=pmorel@linux.ibm.com \
    --cc=robin.murphy@arm.com \
    --cc=schnelle@linux.ibm.com \
    --cc=svens@linux.ibm.com \
    --cc=thuth@redhat.com \
    --cc=vneethv@linux.ibm.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