From: David Gibson <david@gibson.dropbear.id.au> To: Jason Gunthorpe <jgg@nvidia.com> Cc: Liu Yi L <yi.l.liu@intel.com>, alex.williamson@redhat.com, hch@lst.de, jasowang@redhat.com, joro@8bytes.org, jean-philippe@linaro.org, kevin.tian@intel.com, parav@mellanox.com, lkml@metux.net, pbonzini@redhat.com, lushenming@huawei.com, eric.auger@redhat.com, corbet@lwn.net, ashok.raj@intel.com, yi.l.liu@linux.intel.com, jun.j.tian@intel.com, hao.wu@intel.com, dave.jiang@intel.com, jacob.jun.pan@linux.intel.com, kwankhede@nvidia.com, robin.murphy@arm.com, kvm@vger.kernel.org, iommu@lists.linux-foundation.org, dwmw2@infradead.org, linux-kernel@vger.kernel.org, baolu.lu@linux.intel.com, nicolinc@nvidia.com Subject: Re: [RFC 11/20] iommu/iommufd: Add IOMMU_IOASID_ALLOC/FREE Date: Mon, 11 Oct 2021 17:02:01 +1100 [thread overview] Message-ID: <YWPTWdHhoI4k0Ksc@yekko> (raw) In-Reply-To: <20211001122225.GK964074@nvidia.com> [-- Attachment #1: Type: text/plain, Size: 7026 bytes --] On Fri, Oct 01, 2021 at 09:22:25AM -0300, Jason Gunthorpe wrote: > On Fri, Oct 01, 2021 at 04:13:58PM +1000, David Gibson wrote: > > On Tue, Sep 21, 2021 at 02:44:38PM -0300, Jason Gunthorpe wrote: > > > On Sun, Sep 19, 2021 at 02:38:39PM +0800, Liu Yi L wrote: > > > > This patch adds IOASID allocation/free interface per iommufd. When > > > > allocating an IOASID, userspace is expected to specify the type and > > > > format information for the target I/O page table. > > > > > > > > This RFC supports only one type (IOMMU_IOASID_TYPE_KERNEL_TYPE1V2), > > > > implying a kernel-managed I/O page table with vfio type1v2 mapping > > > > semantics. For this type the user should specify the addr_width of > > > > the I/O address space and whether the I/O page table is created in > > > > an iommu enfore_snoop format. enforce_snoop must be true at this point, > > > > as the false setting requires additional contract with KVM on handling > > > > WBINVD emulation, which can be added later. > > > > > > > > Userspace is expected to call IOMMU_CHECK_EXTENSION (see next patch) > > > > for what formats can be specified when allocating an IOASID. > > > > > > > > Open: > > > > - Devices on PPC platform currently use a different iommu driver in vfio. > > > > Per previous discussion they can also use vfio type1v2 as long as there > > > > is a way to claim a specific iova range from a system-wide address space. > > > > This requirement doesn't sound PPC specific, as addr_width for pci devices > > > > can be also represented by a range [0, 2^addr_width-1]. This RFC hasn't > > > > adopted this design yet. We hope to have formal alignment in v1 discussion > > > > and then decide how to incorporate it in v2. > > > > > > I think the request was to include a start/end IO address hint when > > > creating the ios. When the kernel creates it then it can return the > > > actual geometry including any holes via a query. > > > > So part of the point of specifying start/end addresses is that > > explicitly querying holes shouldn't be necessary: if the requested > > range crosses a hole, it should fail. If you didn't really need all > > that range, you shouldn't have asked for it. > > > > Which means these aren't really "hints" but optionally supplied > > constraints. > > We have to be very careful here, there are two very different use > cases. When we are talking about the generic API I am mostly > interested to see that applications like DPDK can use this API and be > portable to any IOMMU HW the kernel supports. I view the fact that > there is VFIO PPC specific code in DPDK as a failing of the kernel to > provide a HW abstraction. I would agree. At the time we were making this, we thought there were irreconcilable differences between what could be done with the x86 vs ppc IOMMUs. Turns out we just didn't think it through hard enough to find a common model. > This means we cannot define an input that has a magic HW specific > value. I'm not entirely sure what you mean by that. > DPDK can never provide that portably. Thus all these kinds of > inputs in the generic API need to be hints, if they exist at all. I don't follow your reasoning. First, note that in qemu these valus are *target* hardware specific, not *host* hardware specific. If those requests aren't honoured, qemu cannot faithfully emulate the target hardware and has to fail. That's what I mean when I say this is not a constraint, not a hint. But when I say the constraint is optional, I mean that things which don't have that requirement - like DPDK - shouldn't apply the constraint. > As 'address space size hint'/'address space start hint' is both > generic, useful, and providable by DPDK I think it is OK. Size is certainly providable, and probably useful. For DPDK, I don't think start is useful. > PPC can use > it to pick which of the two page table formats to use for this IOAS if > it wants. Clarification: it's not that each window has a specific page table format. The two windows are independent of each other, which means you can separately select the page table format for each one (although the 32-bit one generally won't be big enough that there's any point selecting something other than a 1-level TCE table). When I say format here, I basically mean number of levels and size of each level - the IOPTE (a.k.a. TCE) format is the same in each case. > The second use case is when we have a userspace driver for a specific > HW IOMMU. Eg a vIOMMU in qemu doing specific PPC/ARM/x86 acceleration. > We can look here for things to make general, but I would expect a > fairly high bar. Instead, I would rather see the userspace driver > communicate with the kernel driver in its own private language, so > that the entire functionality of the unique HW can be used. I don't think we actually need to do this. Or rather, we might want to do this for maximum performance in some cases, but I think we can have something that at least usually works without having explicit host == target logic for each case. I believe this can work (at least when using kernel managed IO page tables) in a lot of cases even with a different vIOMMU from the host IOMMU. e.g. suppose the host is some x86 (or arm, or whatever) machine with an IOMMU capable of translating any address from 0..2^60, with maybe the exception of an IO hole somewhere between 2GiB and 4GiB. qemu wants to emulate a PAPR vIOMMU, so it says (via interfaces yet to be determined) that it needs an IOAS where things can be mapped in the range 0..2GiB (for the 32-bit window) and 2^59..2^59+1TiB (for the 64-bit window). Ideally the host /dev/iommu will say "ok!", since both those ranges are within the 0..2^60 translated range of the host IOMMU, and don't touch the IO hole. When the guest calls the IO mapping hypercalls, qemu translates those into DMA_MAP operations, and since they're all within the previously verified windows, they should work fine. > So, when it comes to providing exact ranges as an input parameter we > have to decide if that is done as some additional general data, or if > it should be part of a IOAS_FORMAT_KERNEL_PPC. In this case I suggest > the guiding factor should be if every single IOMMU implementation can > be updated to support the value. No, I don't think that needs to be a condition. I think it's perfectly reasonable for a constraint to be given, and for the host IOMMU to just say "no, I can't do that". But that does mean that each of these values has to have an explicit way of userspace specifying "I don't care", so that the kernel will select a suitable value for those instead - that's what DPDK or other userspace would use nearly all the time. -- 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: David Gibson <david@gibson.dropbear.id.au> To: Jason Gunthorpe <jgg@nvidia.com> Cc: kvm@vger.kernel.org, jasowang@redhat.com, kwankhede@nvidia.com, hch@lst.de, jean-philippe@linaro.org, dave.jiang@intel.com, ashok.raj@intel.com, corbet@lwn.net, kevin.tian@intel.com, parav@mellanox.com, alex.williamson@redhat.com, lkml@metux.net, dwmw2@infradead.org, jun.j.tian@intel.com, linux-kernel@vger.kernel.org, lushenming@huawei.com, iommu@lists.linux-foundation.org, pbonzini@redhat.com, robin.murphy@arm.com Subject: Re: [RFC 11/20] iommu/iommufd: Add IOMMU_IOASID_ALLOC/FREE Date: Mon, 11 Oct 2021 17:02:01 +1100 [thread overview] Message-ID: <YWPTWdHhoI4k0Ksc@yekko> (raw) In-Reply-To: <20211001122225.GK964074@nvidia.com> [-- Attachment #1.1: Type: text/plain, Size: 7026 bytes --] On Fri, Oct 01, 2021 at 09:22:25AM -0300, Jason Gunthorpe wrote: > On Fri, Oct 01, 2021 at 04:13:58PM +1000, David Gibson wrote: > > On Tue, Sep 21, 2021 at 02:44:38PM -0300, Jason Gunthorpe wrote: > > > On Sun, Sep 19, 2021 at 02:38:39PM +0800, Liu Yi L wrote: > > > > This patch adds IOASID allocation/free interface per iommufd. When > > > > allocating an IOASID, userspace is expected to specify the type and > > > > format information for the target I/O page table. > > > > > > > > This RFC supports only one type (IOMMU_IOASID_TYPE_KERNEL_TYPE1V2), > > > > implying a kernel-managed I/O page table with vfio type1v2 mapping > > > > semantics. For this type the user should specify the addr_width of > > > > the I/O address space and whether the I/O page table is created in > > > > an iommu enfore_snoop format. enforce_snoop must be true at this point, > > > > as the false setting requires additional contract with KVM on handling > > > > WBINVD emulation, which can be added later. > > > > > > > > Userspace is expected to call IOMMU_CHECK_EXTENSION (see next patch) > > > > for what formats can be specified when allocating an IOASID. > > > > > > > > Open: > > > > - Devices on PPC platform currently use a different iommu driver in vfio. > > > > Per previous discussion they can also use vfio type1v2 as long as there > > > > is a way to claim a specific iova range from a system-wide address space. > > > > This requirement doesn't sound PPC specific, as addr_width for pci devices > > > > can be also represented by a range [0, 2^addr_width-1]. This RFC hasn't > > > > adopted this design yet. We hope to have formal alignment in v1 discussion > > > > and then decide how to incorporate it in v2. > > > > > > I think the request was to include a start/end IO address hint when > > > creating the ios. When the kernel creates it then it can return the > > > actual geometry including any holes via a query. > > > > So part of the point of specifying start/end addresses is that > > explicitly querying holes shouldn't be necessary: if the requested > > range crosses a hole, it should fail. If you didn't really need all > > that range, you shouldn't have asked for it. > > > > Which means these aren't really "hints" but optionally supplied > > constraints. > > We have to be very careful here, there are two very different use > cases. When we are talking about the generic API I am mostly > interested to see that applications like DPDK can use this API and be > portable to any IOMMU HW the kernel supports. I view the fact that > there is VFIO PPC specific code in DPDK as a failing of the kernel to > provide a HW abstraction. I would agree. At the time we were making this, we thought there were irreconcilable differences between what could be done with the x86 vs ppc IOMMUs. Turns out we just didn't think it through hard enough to find a common model. > This means we cannot define an input that has a magic HW specific > value. I'm not entirely sure what you mean by that. > DPDK can never provide that portably. Thus all these kinds of > inputs in the generic API need to be hints, if they exist at all. I don't follow your reasoning. First, note that in qemu these valus are *target* hardware specific, not *host* hardware specific. If those requests aren't honoured, qemu cannot faithfully emulate the target hardware and has to fail. That's what I mean when I say this is not a constraint, not a hint. But when I say the constraint is optional, I mean that things which don't have that requirement - like DPDK - shouldn't apply the constraint. > As 'address space size hint'/'address space start hint' is both > generic, useful, and providable by DPDK I think it is OK. Size is certainly providable, and probably useful. For DPDK, I don't think start is useful. > PPC can use > it to pick which of the two page table formats to use for this IOAS if > it wants. Clarification: it's not that each window has a specific page table format. The two windows are independent of each other, which means you can separately select the page table format for each one (although the 32-bit one generally won't be big enough that there's any point selecting something other than a 1-level TCE table). When I say format here, I basically mean number of levels and size of each level - the IOPTE (a.k.a. TCE) format is the same in each case. > The second use case is when we have a userspace driver for a specific > HW IOMMU. Eg a vIOMMU in qemu doing specific PPC/ARM/x86 acceleration. > We can look here for things to make general, but I would expect a > fairly high bar. Instead, I would rather see the userspace driver > communicate with the kernel driver in its own private language, so > that the entire functionality of the unique HW can be used. I don't think we actually need to do this. Or rather, we might want to do this for maximum performance in some cases, but I think we can have something that at least usually works without having explicit host == target logic for each case. I believe this can work (at least when using kernel managed IO page tables) in a lot of cases even with a different vIOMMU from the host IOMMU. e.g. suppose the host is some x86 (or arm, or whatever) machine with an IOMMU capable of translating any address from 0..2^60, with maybe the exception of an IO hole somewhere between 2GiB and 4GiB. qemu wants to emulate a PAPR vIOMMU, so it says (via interfaces yet to be determined) that it needs an IOAS where things can be mapped in the range 0..2GiB (for the 32-bit window) and 2^59..2^59+1TiB (for the 64-bit window). Ideally the host /dev/iommu will say "ok!", since both those ranges are within the 0..2^60 translated range of the host IOMMU, and don't touch the IO hole. When the guest calls the IO mapping hypercalls, qemu translates those into DMA_MAP operations, and since they're all within the previously verified windows, they should work fine. > So, when it comes to providing exact ranges as an input parameter we > have to decide if that is done as some additional general data, or if > it should be part of a IOAS_FORMAT_KERNEL_PPC. In this case I suggest > the guiding factor should be if every single IOMMU implementation can > be updated to support the value. No, I don't think that needs to be a condition. I think it's perfectly reasonable for a constraint to be given, and for the host IOMMU to just say "no, I can't do that". But that does mean that each of these values has to have an explicit way of userspace specifying "I don't care", so that the kernel will select a suitable value for those instead - that's what DPDK or other userspace would use nearly all the time. -- 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 [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-10-11 7:19 UTC|newest] Thread overview: 537+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-19 6:38 [RFC 00/20] Introduce /dev/iommu for userspace I/O address space management Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-19 6:38 ` [RFC 01/20] iommu/iommufd: Add /dev/iommu core Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-21 15:41 ` Jason Gunthorpe 2021-09-21 15:41 ` Jason Gunthorpe via iommu 2021-09-22 1:51 ` Tian, Kevin 2021-09-22 1:51 ` Tian, Kevin 2021-09-22 12:40 ` Jason Gunthorpe 2021-09-22 12:40 ` Jason Gunthorpe via iommu 2021-09-22 13:59 ` Tian, Kevin 2021-09-22 13:59 ` Tian, Kevin 2021-09-22 14:10 ` Jason Gunthorpe 2021-09-22 14:10 ` Jason Gunthorpe via iommu 2021-10-15 9:18 ` Liu, Yi L 2021-10-15 9:18 ` Liu, Yi L 2021-10-15 11:18 ` Jason Gunthorpe 2021-10-15 11:18 ` Jason Gunthorpe via iommu 2021-10-15 11:29 ` Liu, Yi L 2021-10-15 11:29 ` Liu, Yi L 2021-10-19 16:57 ` Jacob Pan 2021-10-19 16:57 ` Jacob Pan 2021-10-19 16:57 ` Jason Gunthorpe 2021-10-19 16:57 ` Jason Gunthorpe via iommu 2021-10-19 17:11 ` Jacob Pan 2021-10-19 17:11 ` Jacob Pan 2021-10-19 17:12 ` Jason Gunthorpe 2021-10-19 17:12 ` Jason Gunthorpe via iommu 2021-09-19 6:38 ` [RFC 02/20] vfio: Add device class for /dev/vfio/devices Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-21 15:57 ` Jason Gunthorpe 2021-09-21 15:57 ` Jason Gunthorpe via iommu 2021-09-21 23:56 ` Tian, Kevin 2021-09-21 23:56 ` Tian, Kevin 2021-09-22 0:55 ` Jason Gunthorpe 2021-09-22 0:55 ` Jason Gunthorpe via iommu 2021-09-22 1:07 ` Tian, Kevin 2021-09-22 1:07 ` Tian, Kevin 2021-09-22 12:31 ` Jason Gunthorpe 2021-09-22 12:31 ` Jason Gunthorpe via iommu 2021-09-22 3:22 ` Tian, Kevin 2021-09-22 3:22 ` Tian, Kevin 2021-09-22 12:50 ` Jason Gunthorpe 2021-09-22 12:50 ` Jason Gunthorpe via iommu 2021-09-22 14:09 ` Tian, Kevin 2021-09-22 14:09 ` Tian, Kevin 2021-09-21 19:56 ` Alex Williamson 2021-09-21 19:56 ` Alex Williamson 2021-09-22 0:56 ` Tian, Kevin 2021-09-22 0:56 ` Tian, Kevin 2021-09-29 2:08 ` David Gibson 2021-09-29 2:08 ` David Gibson 2021-09-29 19:05 ` Alex Williamson 2021-09-29 19:05 ` Alex Williamson 2021-09-30 2:43 ` David Gibson 2021-09-30 2:43 ` David Gibson 2021-10-20 12:39 ` Liu, Yi L 2021-10-20 12:39 ` Liu, Yi L 2021-09-19 6:38 ` [RFC 03/20] vfio: Add vfio_[un]register_device() Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-21 16:01 ` Jason Gunthorpe 2021-09-21 16:01 ` Jason Gunthorpe via iommu 2021-09-21 23:10 ` Tian, Kevin 2021-09-21 23:10 ` Tian, Kevin 2021-09-22 0:53 ` Jason Gunthorpe 2021-09-22 0:53 ` Jason Gunthorpe via iommu 2021-09-22 0:59 ` Tian, Kevin 2021-09-22 0:59 ` Tian, Kevin 2021-09-22 9:23 ` Tian, Kevin 2021-09-22 9:23 ` Tian, Kevin 2021-09-22 12:22 ` Jason Gunthorpe 2021-09-22 12:22 ` Jason Gunthorpe via iommu 2021-09-22 13:44 ` Tian, Kevin 2021-09-22 13:44 ` Tian, Kevin 2021-09-22 20:10 ` Alex Williamson 2021-09-22 20:10 ` Alex Williamson 2021-09-22 22:34 ` Tian, Kevin 2021-09-22 22:34 ` Tian, Kevin 2021-09-22 22:45 ` Alex Williamson 2021-09-22 22:45 ` Alex Williamson 2021-09-22 23:45 ` Tian, Kevin 2021-09-22 23:45 ` Tian, Kevin 2021-09-22 23:52 ` Jason Gunthorpe 2021-09-22 23:52 ` Jason Gunthorpe via iommu 2021-09-23 0:38 ` Tian, Kevin 2021-09-23 0:38 ` Tian, Kevin 2021-09-22 23:56 ` Jason Gunthorpe 2021-09-22 23:56 ` Jason Gunthorpe via iommu 2021-09-22 0:54 ` Tian, Kevin 2021-09-22 0:54 ` Tian, Kevin 2021-09-22 1:00 ` Jason Gunthorpe 2021-09-22 1:00 ` Jason Gunthorpe via iommu 2021-09-22 1:02 ` Tian, Kevin 2021-09-22 1:02 ` Tian, Kevin 2021-09-23 7:25 ` Eric Auger 2021-09-23 7:25 ` Eric Auger 2021-09-23 11:44 ` Jason Gunthorpe 2021-09-23 11:44 ` Jason Gunthorpe via iommu 2021-09-29 2:46 ` david 2021-09-29 2:46 ` david 2021-09-29 12:22 ` Jason Gunthorpe 2021-09-29 12:22 ` Jason Gunthorpe via iommu 2021-09-30 2:48 ` david 2021-09-30 2:48 ` david 2021-09-29 2:43 ` David Gibson 2021-09-29 2:43 ` David Gibson 2021-09-29 3:40 ` Tian, Kevin 2021-09-29 3:40 ` Tian, Kevin 2021-09-29 5:30 ` Tian, Kevin 2021-09-29 5:30 ` Tian, Kevin 2021-09-29 7:08 ` Cornelia Huck 2021-09-29 7:08 ` Cornelia Huck 2021-09-29 12:15 ` Jason Gunthorpe via iommu 2021-09-29 12:15 ` Jason Gunthorpe 2021-09-19 6:38 ` [RFC 04/20] iommu: Add iommu_device_get_info interface Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-21 16:19 ` Jason Gunthorpe 2021-09-21 16:19 ` Jason Gunthorpe via iommu 2021-09-22 2:31 ` Lu Baolu 2021-09-22 2:31 ` Lu Baolu 2021-09-22 5:07 ` Christoph Hellwig 2021-09-22 5:07 ` Christoph Hellwig 2021-09-29 2:52 ` David Gibson 2021-09-29 2:52 ` David Gibson 2021-09-29 9:25 ` Lu Baolu 2021-09-29 9:25 ` Lu Baolu 2021-09-29 9:29 ` Lu Baolu 2021-09-29 9:29 ` Lu Baolu 2021-09-19 6:38 ` [RFC 05/20] vfio/pci: Register device to /dev/vfio/devices Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-21 16:40 ` Jason Gunthorpe 2021-09-21 16:40 ` Jason Gunthorpe via iommu 2021-09-21 21:09 ` Alex Williamson 2021-09-21 21:09 ` Alex Williamson 2021-09-21 21:58 ` Jason Gunthorpe 2021-09-21 21:58 ` Jason Gunthorpe via iommu 2021-09-22 1:24 ` Tian, Kevin 2021-09-22 1:24 ` Tian, Kevin 2021-09-22 1:19 ` Tian, Kevin 2021-09-22 1:19 ` Tian, Kevin 2021-09-22 21:17 ` Alex Williamson 2021-09-22 21:17 ` Alex Williamson 2021-09-22 23:49 ` Tian, Kevin 2021-09-22 23:49 ` Tian, Kevin 2021-09-19 6:38 ` [RFC 06/20] iommu: Add iommu_device_init[exit]_user_dma interfaces Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-21 17:09 ` Jason Gunthorpe 2021-09-21 17:09 ` Jason Gunthorpe via iommu 2021-09-22 1:47 ` Tian, Kevin 2021-09-22 1:47 ` Tian, Kevin 2021-09-22 12:39 ` Jason Gunthorpe 2021-09-22 12:39 ` Jason Gunthorpe via iommu 2021-09-22 13:56 ` Tian, Kevin 2021-09-22 13:56 ` Tian, Kevin 2021-09-27 9:42 ` Tian, Kevin 2021-09-27 9:42 ` Tian, Kevin 2021-09-27 11:34 ` Lu Baolu 2021-09-27 11:34 ` Lu Baolu 2021-09-27 13:08 ` Tian, Kevin 2021-09-27 13:08 ` Tian, Kevin 2021-09-27 11:53 ` Jason Gunthorpe 2021-09-27 11:53 ` Jason Gunthorpe via iommu 2021-09-27 13:00 ` Tian, Kevin 2021-09-27 13:00 ` Tian, Kevin 2021-09-27 13:09 ` Jason Gunthorpe 2021-09-27 13:09 ` Jason Gunthorpe via iommu 2021-09-27 13:32 ` Tian, Kevin 2021-09-27 14:39 ` Jason Gunthorpe 2021-09-28 7:13 ` Tian, Kevin 2021-09-28 11:54 ` Jason Gunthorpe 2021-09-28 23:59 ` Tian, Kevin 2021-09-27 19:19 ` Alex Williamson 2021-09-28 7:43 ` Tian, Kevin 2021-09-28 16:26 ` Alex Williamson 2021-09-27 15:09 ` Jason Gunthorpe 2021-09-27 15:09 ` Jason Gunthorpe via iommu 2021-09-28 7:30 ` Tian, Kevin 2021-09-28 7:30 ` Tian, Kevin 2021-09-28 11:57 ` Jason Gunthorpe 2021-09-28 11:57 ` Jason Gunthorpe via iommu 2021-09-28 13:35 ` Lu Baolu 2021-09-28 13:35 ` Lu Baolu 2021-09-28 14:07 ` Jason Gunthorpe 2021-09-28 14:07 ` Jason Gunthorpe via iommu 2021-09-29 0:38 ` Tian, Kevin 2021-09-29 0:38 ` Tian, Kevin 2021-09-29 12:59 ` Jason Gunthorpe 2021-09-29 12:59 ` Jason Gunthorpe via iommu 2021-10-15 1:29 ` Tian, Kevin 2021-10-15 1:29 ` Tian, Kevin 2021-10-15 11:09 ` Jason Gunthorpe 2021-10-15 11:09 ` Jason Gunthorpe via iommu 2021-10-18 1:52 ` Tian, Kevin 2021-10-18 1:52 ` Tian, Kevin 2021-09-29 2:22 ` Lu Baolu 2021-09-29 2:22 ` Lu Baolu 2021-09-29 2:29 ` Tian, Kevin 2021-09-29 2:29 ` Tian, Kevin 2021-09-29 2:38 ` Lu Baolu 2021-09-29 2:38 ` Lu Baolu 2021-09-29 4:55 ` David Gibson 2021-09-29 4:55 ` David Gibson 2021-09-29 5:38 ` Tian, Kevin 2021-09-29 5:38 ` Tian, Kevin 2021-09-29 6:35 ` David Gibson 2021-09-29 6:35 ` David Gibson 2021-09-29 7:31 ` Tian, Kevin 2021-09-29 7:31 ` Tian, Kevin 2021-09-30 3:05 ` David Gibson 2021-09-30 3:05 ` David Gibson 2021-09-29 12:57 ` Jason Gunthorpe 2021-09-29 12:57 ` Jason Gunthorpe via iommu 2021-09-30 3:09 ` David Gibson 2021-09-30 3:09 ` David Gibson 2021-09-30 22:28 ` Jason Gunthorpe 2021-09-30 22:28 ` Jason Gunthorpe via iommu 2021-10-01 3:54 ` David Gibson 2021-10-01 3:54 ` David Gibson 2021-09-19 6:38 ` [RFC 07/20] iommu/iommufd: Add iommufd_[un]bind_device() Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-21 17:14 ` Jason Gunthorpe 2021-09-21 17:14 ` Jason Gunthorpe via iommu 2021-10-15 9:21 ` Liu, Yi L 2021-10-15 9:21 ` Liu, Yi L 2021-09-29 5:25 ` David Gibson 2021-09-29 5:25 ` David Gibson 2021-09-29 12:24 ` Jason Gunthorpe 2021-09-29 12:24 ` Jason Gunthorpe via iommu 2021-09-30 3:10 ` David Gibson 2021-09-30 3:10 ` David Gibson 2021-10-01 12:43 ` Jason Gunthorpe 2021-10-01 12:43 ` Jason Gunthorpe via iommu 2021-10-07 1:23 ` David Gibson 2021-10-07 1:23 ` David Gibson 2021-10-07 11:35 ` Jason Gunthorpe 2021-10-07 11:35 ` Jason Gunthorpe via iommu 2021-10-11 3:24 ` David Gibson 2021-10-11 3:24 ` David Gibson 2021-09-19 6:38 ` [RFC 08/20] vfio/pci: Add VFIO_DEVICE_BIND_IOMMUFD Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-19 10:08 ` kernel test robot 2021-09-19 10:08 ` kernel test robot 2021-09-21 17:29 ` Jason Gunthorpe 2021-09-21 17:29 ` Jason Gunthorpe via iommu 2021-09-22 21:01 ` Alex Williamson 2021-09-22 21:01 ` Alex Williamson 2021-09-22 23:01 ` Jason Gunthorpe 2021-09-22 23:01 ` Jason Gunthorpe via iommu 2021-09-29 6:00 ` David Gibson 2021-09-29 6:00 ` David Gibson 2021-09-29 6:41 ` Tian, Kevin 2021-09-29 6:41 ` Tian, Kevin 2021-09-29 12:28 ` Jason Gunthorpe 2021-09-29 12:28 ` Jason Gunthorpe via iommu 2021-09-29 22:34 ` Tian, Kevin 2021-09-29 22:34 ` Tian, Kevin 2021-09-30 3:12 ` David Gibson 2021-09-30 3:12 ` David Gibson 2021-09-19 6:38 ` [RFC 09/20] iommu: Add page size and address width attributes Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-22 13:42 ` Eric Auger 2021-09-22 13:42 ` Eric Auger 2021-09-22 14:19 ` Tian, Kevin 2021-09-22 14:19 ` Tian, Kevin 2021-09-19 6:38 ` [RFC 10/20] iommu/iommufd: Add IOMMU_DEVICE_GET_INFO Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-21 17:40 ` Jason Gunthorpe 2021-09-21 17:40 ` Jason Gunthorpe via iommu 2021-09-22 3:30 ` Tian, Kevin 2021-09-22 3:30 ` Tian, Kevin 2021-09-22 12:41 ` Jason Gunthorpe 2021-09-22 12:41 ` Jason Gunthorpe via iommu 2021-09-29 6:18 ` david 2021-09-29 6:18 ` david 2021-09-22 21:24 ` Alex Williamson 2021-09-22 21:24 ` Alex Williamson 2021-09-22 23:49 ` Jason Gunthorpe 2021-09-22 23:49 ` Jason Gunthorpe via iommu 2021-09-23 3:10 ` Tian, Kevin 2021-09-23 3:10 ` Tian, Kevin 2021-09-23 10:15 ` Jean-Philippe Brucker 2021-09-23 10:15 ` Jean-Philippe Brucker 2021-09-23 11:27 ` Jason Gunthorpe 2021-09-23 11:27 ` Jason Gunthorpe via iommu 2021-09-23 12:05 ` Tian, Kevin 2021-09-23 12:05 ` Tian, Kevin 2021-09-23 12:22 ` Jason Gunthorpe 2021-09-23 12:22 ` Jason Gunthorpe via iommu 2021-09-29 8:48 ` Tian, Kevin 2021-09-29 8:48 ` Tian, Kevin 2021-09-29 12:36 ` Jason Gunthorpe 2021-09-29 12:36 ` Jason Gunthorpe via iommu 2021-09-30 8:30 ` Tian, Kevin 2021-09-30 10:33 ` Jean-Philippe Brucker 2021-09-30 22:04 ` Jason Gunthorpe 2021-10-01 3:28 ` hch 2021-10-14 8:13 ` Tian, Kevin 2021-10-14 8:22 ` hch 2021-10-14 8:29 ` Tian, Kevin 2021-10-14 8:01 ` Tian, Kevin 2021-10-14 9:16 ` Jean-Philippe Brucker 2021-09-30 8:49 ` Tian, Kevin 2021-09-30 8:49 ` Tian, Kevin 2021-09-30 13:43 ` Lu Baolu 2021-09-30 13:43 ` Lu Baolu 2021-10-01 3:24 ` hch 2021-10-01 3:24 ` hch 2021-09-30 22:08 ` Jason Gunthorpe 2021-09-30 22:08 ` Jason Gunthorpe via iommu 2021-09-23 11:36 ` Jason Gunthorpe 2021-09-23 11:36 ` Jason Gunthorpe via iommu [not found] ` <BN9PR11MB5433409DF766AAEF1BB2CF258CA39@BN9PR11MB5433.namprd11.prod.outlook.com> 2021-09-23 3:38 ` Tian, Kevin 2021-09-23 3:38 ` Tian, Kevin 2021-09-23 11:42 ` Jason Gunthorpe 2021-09-23 11:42 ` Jason Gunthorpe via iommu 2021-09-30 9:35 ` Tian, Kevin 2021-09-30 9:35 ` Tian, Kevin 2021-09-30 22:23 ` Jason Gunthorpe 2021-09-30 22:23 ` Jason Gunthorpe via iommu 2021-10-01 3:30 ` hch 2021-10-01 3:30 ` hch 2021-10-14 9:11 ` Tian, Kevin 2021-10-14 9:11 ` Tian, Kevin 2021-10-14 15:42 ` Jason Gunthorpe 2021-10-14 15:42 ` Jason Gunthorpe via iommu 2021-10-15 1:01 ` Tian, Kevin 2021-10-15 1:01 ` Tian, Kevin [not found] ` <BN9PR11MB543327BB6D58AEF91AD2C9D18CB99@BN9PR11MB5433.namprd11.prod.outlook.com> 2021-10-21 2:26 ` Tian, Kevin 2021-10-21 2:26 ` Tian, Kevin 2021-10-21 14:58 ` Jean-Philippe Brucker 2021-10-21 14:58 ` Jean-Philippe Brucker 2021-10-21 23:22 ` Jason Gunthorpe 2021-10-21 23:22 ` Jason Gunthorpe via iommu 2021-10-22 7:49 ` Jean-Philippe Brucker 2021-10-22 7:49 ` Jean-Philippe Brucker 2021-10-25 16:51 ` Jason Gunthorpe 2021-10-25 16:51 ` Jason Gunthorpe via iommu 2021-10-21 23:30 ` Jason Gunthorpe 2021-10-21 23:30 ` Jason Gunthorpe via iommu 2021-10-22 3:08 ` Tian, Kevin 2021-10-22 3:08 ` Tian, Kevin 2021-10-25 23:34 ` Jason Gunthorpe 2021-10-25 23:34 ` Jason Gunthorpe via iommu 2021-10-27 1:42 ` Tian, Kevin 2021-10-27 1:42 ` Tian, Kevin 2021-10-28 2:07 ` Tian, Kevin 2021-10-28 2:07 ` Tian, Kevin 2021-10-29 13:55 ` Jason Gunthorpe 2021-10-29 13:55 ` Jason Gunthorpe via iommu 2021-09-29 6:23 ` David Gibson 2021-09-29 6:23 ` David Gibson 2021-09-19 6:38 ` [RFC 11/20] iommu/iommufd: Add IOMMU_IOASID_ALLOC/FREE Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-19 11:03 ` kernel test robot 2021-09-19 11:03 ` kernel test robot 2021-09-21 17:44 ` Jason Gunthorpe 2021-09-21 17:44 ` Jason Gunthorpe via iommu 2021-09-22 3:40 ` Tian, Kevin 2021-09-22 3:40 ` Tian, Kevin 2021-09-22 14:09 ` Jason Gunthorpe 2021-09-22 14:09 ` Jason Gunthorpe via iommu 2021-09-23 9:14 ` Tian, Kevin 2021-09-23 9:14 ` Tian, Kevin 2021-09-23 12:06 ` Jason Gunthorpe 2021-09-23 12:06 ` Jason Gunthorpe via iommu 2021-09-23 12:22 ` Tian, Kevin 2021-09-23 12:22 ` Tian, Kevin 2021-09-23 12:31 ` Jason Gunthorpe 2021-09-23 12:31 ` Jason Gunthorpe via iommu 2021-09-23 12:45 ` Tian, Kevin 2021-09-23 12:45 ` Tian, Kevin 2021-09-23 13:01 ` Jason Gunthorpe 2021-09-23 13:01 ` Jason Gunthorpe via iommu 2021-09-23 13:20 ` Tian, Kevin 2021-09-23 13:20 ` Tian, Kevin 2021-09-23 13:30 ` Jason Gunthorpe 2021-09-23 13:30 ` Jason Gunthorpe via iommu 2021-09-23 13:41 ` Tian, Kevin 2021-09-23 13:41 ` Tian, Kevin 2021-10-01 6:30 ` david 2021-10-01 6:30 ` david 2021-10-01 6:26 ` david 2021-10-01 6:26 ` david 2021-10-01 6:19 ` david 2021-10-01 6:19 ` david 2021-10-01 12:25 ` Jason Gunthorpe 2021-10-01 12:25 ` Jason Gunthorpe via iommu 2021-10-02 4:21 ` david 2021-10-02 4:21 ` david 2021-10-02 12:25 ` Jason Gunthorpe 2021-10-02 12:25 ` Jason Gunthorpe via iommu 2021-10-11 5:37 ` david 2021-10-11 5:37 ` david 2021-10-11 17:17 ` Jason Gunthorpe 2021-10-11 17:17 ` Jason Gunthorpe via iommu 2021-10-14 4:33 ` david 2021-10-14 4:33 ` david 2021-10-14 15:06 ` Jason Gunthorpe via iommu 2021-10-14 15:06 ` Jason Gunthorpe 2021-10-18 3:40 ` david 2021-10-18 3:40 ` david 2021-10-01 6:15 ` david 2021-10-01 6:15 ` david 2021-09-22 12:51 ` Liu, Yi L 2021-09-22 12:51 ` Liu, Yi L 2021-09-22 13:32 ` Jason Gunthorpe 2021-09-22 13:32 ` Jason Gunthorpe via iommu 2021-09-23 6:26 ` Liu, Yi L 2021-09-23 6:26 ` Liu, Yi L 2021-10-01 6:13 ` David Gibson 2021-10-01 6:13 ` David Gibson 2021-10-01 12:22 ` Jason Gunthorpe 2021-10-01 12:22 ` Jason Gunthorpe via iommu 2021-10-11 6:02 ` David Gibson [this message] 2021-10-11 6:02 ` David Gibson 2021-10-11 8:49 ` Jean-Philippe Brucker 2021-10-11 8:49 ` Jean-Philippe Brucker 2021-10-11 23:38 ` Jason Gunthorpe 2021-10-11 23:38 ` Jason Gunthorpe via iommu 2021-10-12 8:33 ` Jean-Philippe Brucker 2021-10-12 8:33 ` Jean-Philippe Brucker 2021-10-13 7:14 ` Tian, Kevin 2021-10-13 7:14 ` Tian, Kevin 2021-10-13 7:07 ` Tian, Kevin 2021-10-13 7:07 ` Tian, Kevin 2021-10-14 4:38 ` David Gibson 2021-10-14 4:38 ` David Gibson 2021-10-11 18:49 ` Jason Gunthorpe 2021-10-11 18:49 ` Jason Gunthorpe via iommu 2021-10-14 4:53 ` David Gibson 2021-10-14 4:53 ` David Gibson 2021-10-14 14:52 ` Jason Gunthorpe 2021-10-14 14:52 ` Jason Gunthorpe via iommu 2021-10-18 3:50 ` David Gibson 2021-10-18 3:50 ` David Gibson 2021-10-18 17:42 ` Jason Gunthorpe 2021-10-18 17:42 ` Jason Gunthorpe via iommu 2021-09-22 13:45 ` Jean-Philippe Brucker 2021-09-22 13:45 ` Jean-Philippe Brucker 2021-09-29 10:47 ` Liu, Yi L 2021-09-29 10:47 ` Liu, Yi L 2021-10-01 6:11 ` David Gibson 2021-10-01 6:11 ` David Gibson 2021-10-13 7:00 ` Tian, Kevin 2021-10-13 7:00 ` Tian, Kevin 2021-10-14 5:00 ` David Gibson 2021-10-14 5:00 ` David Gibson 2021-10-14 6:53 ` Tian, Kevin 2021-10-14 6:53 ` Tian, Kevin 2021-10-25 5:05 ` David Gibson 2021-10-25 5:05 ` David Gibson 2021-10-27 2:32 ` Tian, Kevin 2021-10-27 2:32 ` Tian, Kevin 2021-09-19 6:38 ` [RFC 12/20] iommu/iommufd: Add IOMMU_CHECK_EXTENSION Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-21 17:47 ` Jason Gunthorpe 2021-09-21 17:47 ` Jason Gunthorpe via iommu 2021-09-22 3:41 ` Tian, Kevin 2021-09-22 3:41 ` Tian, Kevin 2021-09-22 12:55 ` Jason Gunthorpe 2021-09-22 12:55 ` Jason Gunthorpe via iommu 2021-09-22 14:13 ` Tian, Kevin 2021-09-19 6:38 ` [RFC 13/20] iommu: Extend iommu_at[de]tach_device() for multiple devices group Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-10-14 5:24 ` David Gibson 2021-10-14 5:24 ` David Gibson 2021-10-14 7:06 ` Tian, Kevin 2021-10-14 7:06 ` Tian, Kevin 2021-10-18 3:57 ` David Gibson 2021-10-18 3:57 ` David Gibson 2021-10-18 16:32 ` Jason Gunthorpe 2021-10-18 16:32 ` Jason Gunthorpe via iommu 2021-10-25 5:14 ` David Gibson 2021-10-25 5:14 ` David Gibson 2021-10-25 12:14 ` Jason Gunthorpe 2021-10-25 12:14 ` Jason Gunthorpe via iommu 2021-10-25 13:16 ` David Gibson 2021-10-25 13:16 ` David Gibson 2021-10-25 23:36 ` Jason Gunthorpe 2021-10-25 23:36 ` Jason Gunthorpe via iommu 2021-10-26 9:23 ` David Gibson 2021-10-26 9:23 ` David Gibson 2021-09-19 6:38 ` [RFC 14/20] iommu/iommufd: Add iommufd_device_[de]attach_ioasid() Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-21 18:02 ` Jason Gunthorpe 2021-09-21 18:02 ` Jason Gunthorpe via iommu 2021-09-22 3:53 ` Tian, Kevin 2021-09-22 3:53 ` Tian, Kevin 2021-09-22 12:57 ` Jason Gunthorpe 2021-09-22 12:57 ` Jason Gunthorpe via iommu 2021-09-22 14:16 ` Tian, Kevin 2021-09-22 14:16 ` Tian, Kevin 2021-09-19 6:38 ` [RFC 15/20] vfio/pci: Add VFIO_DEVICE_[DE]ATTACH_IOASID Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-21 18:04 ` Jason Gunthorpe 2021-09-21 18:04 ` Jason Gunthorpe via iommu 2021-09-22 3:56 ` Tian, Kevin 2021-09-22 3:56 ` Tian, Kevin 2021-09-22 12:58 ` Jason Gunthorpe 2021-09-22 12:58 ` Jason Gunthorpe via iommu 2021-09-22 14:17 ` Tian, Kevin 2021-09-22 14:17 ` Tian, Kevin 2021-09-19 6:38 ` [RFC 16/20] vfio/type1: Export symbols for dma [un]map code sharing Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-21 18:14 ` Jason Gunthorpe 2021-09-21 18:14 ` Jason Gunthorpe via iommu 2021-09-22 3:57 ` Tian, Kevin 2021-09-22 3:57 ` Tian, Kevin 2021-09-19 6:38 ` [RFC 17/20] iommu/iommufd: Report iova range to userspace Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-19 9:38 ` kernel test robot 2021-09-19 16:41 ` kernel test robot 2021-09-22 14:49 ` Jean-Philippe Brucker 2021-09-22 14:49 ` Jean-Philippe Brucker 2021-09-29 10:44 ` Liu, Yi L 2021-09-29 10:44 ` Liu, Yi L 2021-09-29 12:07 ` Jean-Philippe Brucker 2021-09-29 12:07 ` Jean-Philippe Brucker 2021-09-29 12:31 ` Jason Gunthorpe 2021-09-29 12:31 ` Jason Gunthorpe via iommu 2021-09-19 6:38 ` [RFC 18/20] iommu/iommufd: Add IOMMU_[UN]MAP_DMA on IOASID Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-19 11:53 ` kernel test robot 2021-09-19 6:38 ` [RFC 19/20] iommu/vt-d: Implement device_info iommu_ops callback Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-19 6:38 ` [RFC 20/20] Doc: Add documentation for /dev/iommu Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-10-29 0:15 ` David Gibson 2021-10-29 0:15 ` David Gibson 2021-10-29 12:44 ` Jason Gunthorpe 2021-10-29 12:44 ` Jason Gunthorpe via iommu 2021-09-19 6:45 ` [RFC 00/20] Introduce /dev/iommu for userspace I/O address space management Liu, Yi L 2021-09-19 6:45 ` Liu, Yi L 2021-09-21 13:45 ` Jason Gunthorpe 2021-09-21 13:45 ` Jason Gunthorpe via iommu 2021-09-22 3:25 ` Liu, Yi L 2021-09-22 3:25 ` Liu, Yi L
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=YWPTWdHhoI4k0Ksc@yekko \ --to=david@gibson.dropbear.id.au \ --cc=alex.williamson@redhat.com \ --cc=ashok.raj@intel.com \ --cc=baolu.lu@linux.intel.com \ --cc=corbet@lwn.net \ --cc=dave.jiang@intel.com \ --cc=dwmw2@infradead.org \ --cc=eric.auger@redhat.com \ --cc=hao.wu@intel.com \ --cc=hch@lst.de \ --cc=iommu@lists.linux-foundation.org \ --cc=jacob.jun.pan@linux.intel.com \ --cc=jasowang@redhat.com \ --cc=jean-philippe@linaro.org \ --cc=jgg@nvidia.com \ --cc=joro@8bytes.org \ --cc=jun.j.tian@intel.com \ --cc=kevin.tian@intel.com \ --cc=kvm@vger.kernel.org \ --cc=kwankhede@nvidia.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lkml@metux.net \ --cc=lushenming@huawei.com \ --cc=nicolinc@nvidia.com \ --cc=parav@mellanox.com \ --cc=pbonzini@redhat.com \ --cc=robin.murphy@arm.com \ --cc=yi.l.liu@intel.com \ --cc=yi.l.liu@linux.intel.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.