[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YNQCJfU/G5uwDCSE@yekko>
Date: Thu, 24 Jun 2021 13:55:17 +1000
From: David Gibson <david@...son.dropbear.id.au>
To: "Tian, Kevin" <kevin.tian@...el.com>
Cc: Jean-Philippe Brucker <jean-philippe@...aro.org>,
"Alex Williamson (alex.williamson@...hat.com)"
<alex.williamson@...hat.com>, "Raj, Ashok" <ashok.raj@...el.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
Jonathan Corbet <corbet@....net>,
Robin Murphy <robin.murphy@....com>,
LKML <linux-kernel@...r.kernel.org>,
Kirti Wankhede <kwankhede@...dia.com>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
Jason Gunthorpe <jgg@...dia.com>,
"Jiang, Dave" <dave.jiang@...el.com>,
David Woodhouse <dwmw2@...radead.org>,
Jason Wang <jasowang@...hat.com>
Subject: Re: [RFC] /dev/ioasid uAPI proposal
On Wed, Jun 23, 2021 at 08:00:49AM +0000, Tian, Kevin wrote:
> > From: David Gibson
> > Sent: Thursday, June 17, 2021 12:08 PM
> >
> > On Thu, Jun 03, 2021 at 08:12:27AM +0000, Tian, Kevin wrote:
> > > > From: David Gibson <david@...son.dropbear.id.au>
> > > > Sent: Wednesday, June 2, 2021 2:15 PM
> > > >
> > > [...]
> > >
> > > > >
> > > > > /*
> > > > > * Get information about an I/O address space
> > > > > *
> > > > > * Supported capabilities:
> > > > > * - VFIO type1 map/unmap;
> > > > > * - pgtable/pasid_table binding
> > > > > * - hardware nesting vs. software nesting;
> > > > > * - ...
> > > > > *
> > > > > * Related attributes:
> > > > > * - supported page sizes, reserved IOVA ranges (DMA
> > mapping);
> > > >
> > > > Can I request we represent this in terms of permitted IOVA ranges,
> > > > rather than reserved IOVA ranges. This works better with the "window"
> > > > model I have in mind for unifying the restrictions of the POWER IOMMU
> > > > with Type1 like mapping.
> > >
> > > Can you elaborate how permitted range work better here?
> >
> > Pretty much just that MAP operations would fail if they don't entirely
> > lie within a permitted range. So, for example if your IOMMU only
> > implements say, 45 bits of IOVA, then you'd have 0..0x1fffffffffff as
> > your only permitted range. If, like the POWER paravirtual IOMMU (in
> > defaut configuration) you have a small (1G) 32-bit range and a large
> > (45-bit) 64-bit range at a high address, you'd have say:
> > 0x00000000..0x3fffffff (32-bit range)
> > and
> > 0x800000000000000 .. 0x8001fffffffffff (64-bit range)
> > as your permitted ranges.
> >
> > If your IOMMU supports truly full 64-bit addressing, but has a
> > reserved range (for MSIs or whatever) at 0xaaaa000..0xbbbb0000 then
> > you'd have permitted ranges of 0..0xaaa9ffff and
> > 0xbbbb0000..0xffffffffffffffff.
>
> I see. Has incorporated this comment in v2.
>
> >
> > [snip]
> > > > For debugging and certain hypervisor edge cases it might be useful to
> > > > have a call to allow userspace to lookup and specific IOVA in a guest
> > > > managed pgtable.
> > >
> > > Since all the mapping metadata is from userspace, why would one
> > > rely on the kernel to provide such service? Or are you simply asking
> > > for some debugfs node to dump the I/O page table for a given
> > > IOASID?
> >
> > I'm thinking of this as a debugging aid so you can make sure that how
> > the kernel is interpreting that metadata in the same way that your
> > userspace expects it to interpret that metadata.
> >
>
> I'll not include it in this RFC. There are already too many stuff. The
> debugging aid can be added anyway when it's actually required.
Fair enough.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists