From: David Gibson <david@gibson.dropbear.id.au> To: "Tian, Kevin" <kevin.tian@intel.com> Cc: Jason Gunthorpe <jgg@nvidia.com>, Alex Williamson <alex.williamson@redhat.com>, Lu Baolu <baolu.lu@linux.intel.com>, Chaitanya Kulkarni <chaitanyak@nvidia.com>, Cornelia Huck <cohuck@redhat.com>, Daniel Jordan <daniel.m.jordan@oracle.com>, Eric Auger <eric.auger@redhat.com>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, Jason Wang <jasowang@redhat.com>, Jean-Philippe Brucker <jean-philippe@linaro.org>, "Martins, Joao" <joao.m.martins@oracle.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, Matthew Rosato <mjrosato@linux.ibm.com>, "Michael S. Tsirkin" <mst@redhat.com>, Nicolin Chen <nicolinc@nvidia.com>, Niklas Schnelle <schnelle@linux.ibm.com>, Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>, "Liu, Yi L" <yi.l.liu@intel.com>, Keqian Zhu <zhukeqian1@huawei.com> Subject: Re: [PATCH RFC 11/12] iommufd: vfio container FD ioctl compatibility Date: Fri, 13 May 2022 14:35:46 +1000 [thread overview] Message-ID: <Yn3gIiGLyHB/5kN4@yekko> (raw) In-Reply-To: <BN9PR11MB52765D95C6172ABE43E236A38CC89@BN9PR11MB5276.namprd11.prod.outlook.com> [-- Attachment #1: Type: text/plain, Size: 8026 bytes --] On Wed, May 11, 2022 at 03:15:22AM +0000, Tian, Kevin wrote: > > From: Jason Gunthorpe <jgg@nvidia.com> > > Sent: Wednesday, May 11, 2022 3:00 AM > > > > On Tue, May 10, 2022 at 05:12:04PM +1000, David Gibson wrote: > > > Ok... here's a revised version of my proposal which I think addresses > > > your concerns and simplfies things. > > > > > > - No new operations, but IOAS_MAP gets some new flags (and IOAS_COPY > > > will probably need matching changes) > > > > > > - By default the IOVA given to IOAS_MAP is a hint only, and the IOVA > > > is chosen by the kernel within the aperture(s). This is closer to > > > how mmap() operates, and DPDK and similar shouldn't care about > > > having specific IOVAs, even at the individual mapping level. > > > > > > - IOAS_MAP gets an IOMAP_FIXED flag, analagous to mmap()'s MAP_FIXED, > > > for when you really do want to control the IOVA (qemu, maybe some > > > special userspace driver cases) > > > > We already did both of these, the flag is called > > IOMMU_IOAS_MAP_FIXED_IOVA - if it is not specified then kernel will > > select the IOVA internally. > > > > > - ATTACH will fail if the new device would shrink the aperture to > > > exclude any already established mappings (I assume this is already > > > the case) > > > > Yes > > > > > - IOAS_MAP gets an IOMAP_RESERVE flag, which operates a bit like a > > > PROT_NONE mmap(). It reserves that IOVA space, so other (non-FIXED) > > > MAPs won't use it, but doesn't actually put anything into the IO > > > pagetables. > > > - Like a regular mapping, ATTACHes that are incompatible with an > > > IOMAP_RESERVEed region will fail > > > - An IOMAP_RESERVEed area can be overmapped with an IOMAP_FIXED > > > mapping > > > > Yeah, this seems OK, I'm thinking a new API might make sense because > > you don't really want mmap replacement semantics but a permanent > > record of what IOVA must always be valid. > > > > IOMMU_IOA_REQUIRE_IOVA perhaps, similar signature to > > IOMMUFD_CMD_IOAS_IOVA_RANGES: > > > > struct iommu_ioas_require_iova { > > __u32 size; > > __u32 ioas_id; > > __u32 num_iovas; > > __u32 __reserved; > > struct iommu_required_iovas { > > __aligned_u64 start; > > __aligned_u64 last; > > } required_iovas[]; > > }; > > As a permanent record do we want to enforce that once the required > range list is set all FIXED and non-FIXED allocations must be within the > list of ranges? No, I don't think so. In fact the way I was envisaging this, non-FIXED mappings will *never* go into the reserved ranges. This is for the benefit of any use cases that need both mappings where they don't care about the IOVA and those which do. Essentially, reserving a region here is saying to the kernel "I want to manage this IOVA space; make sure nothing else touches it". That means both that the kernel must disallow any hw associated changes (like ATTACH) which would impinge on the reserved region, and also any IOVA allocations that would take parts away from that space. Whether we want to restrict FIXED mappings to the reserved regions is an interesting question. I wasn't thinking that would be necessary (just as you can use mmap() MAP_FIXED anywhere). However.. much as MAP_FIXED is very dangerous to use if you don't previously reserve address space, I think IOMAP_FIXED is dangerous if you haven't previously reserved space. So maybe it would make sense to only allow FIXED mappings within reserved regions. Strictly dividing the IOVA space into kernel managed and user managed regions does make a certain amount of sense. > If yes we can take the end of the last range as the max size of the iova > address space to optimize the page table layout. > > otherwise we may need another dedicated hint for that optimization. Right. With the revised model where reserving windows is optional, not required, I don't think we can quite re-use this for optimization hints. Which is a bit unfortunate. I can't immediately see a way to tweak this which handles both more neatly, but I like the idea if we can figure out a way. > > > So, for DPDK the sequence would be: > > > > > > 1. Create IOAS > > > 2. ATTACH devices > > > 3. IOAS_MAP some stuff > > > 4. Do DMA with the IOVAs that IOAS_MAP returned > > > > > > (Note, not even any need for QUERY in simple cases) > > > > Yes, this is done already > > > > > For (unoptimized) qemu it would be: > > > > > > 1. Create IOAS > > > 2. IOAS_MAP(IOMAP_FIXED|IOMAP_RESERVE) the valid IOVA regions of > > the > > > guest platform > > > 3. ATTACH devices (this will fail if they're not compatible with the > > > reserved IOVA regions) > > > 4. Boot the guest > > I suppose above is only the sample flow for PPC vIOMMU. For non-PPC > vIOMMUs regular mappings are required before booting the guest and > reservation might be done but not mandatory (at least not what current > Qemu vfio can afford as it simply replays valid ranges in the CPU address > space). That was a somewhat simplified description. When we look in more detail, I think the ppc and x86 models become more similar. So, in more detail, I think it would look like this: 1. Create base IOAS 2. Map guest memory into base IOAS so that IOVA==GPA 3. Create IOASes for each vIOMMU domain 4. Reserve windows in domain IOASes where the vIOMMU will allow mappings by default 5. ATTACH devices to appropriate IOASes (***) 6. Boot the guest On guest map/invalidate: Use IOAS_COPY to take mappings from base IOAS and put them into the domain IOAS On memory hotplug: IOAS_MAP new memory block into base IOAS On dev hotplug: (***) ATTACH devices to appropriate IOAS On guest reconfiguration of vIOMMU domains (x86 only): DETACH device from base IOAS, attach to vIOMMU domain IOAS On guest reconfiguration of vIOMMU apertures (ppc only): Alter reserved regions to match vIOMMU The difference between ppc and x86 is at the places marked (***): which IOAS each device gets attached to and when. For x86 all devices live in the base IOAS by default, and only get moved to domain IOASes when those domains are set up in the vIOMMU. For POWER each device starts in a domain IOAS based on its guest PE, and never moves. [This is still a bit simplified. In practice, I imagine you'd optimize to only create the domain IOASes at the point they're needed - on boot for ppc, but only when the vIOMMU is configured for x86. I don't think that really changes the model, though.] A few aspects of the model interact quite nicely here. Mapping a large memory guest with IOVA==GPA would probably fail on a ppc host IOMMU. But if both guest and host are ppc, then no devices get attached to that base IOAS, so its apertures don't get restricted by the host hardware. That way we get a common model, and the benefits of GUP sharing via IOAS_COPY, without it failing in the ppc-on-ppc case. x86-on-ppc and ppc-on-x86 will probably only work in limited cases where the various sizes and windows line up, but the possibility isn't precluded by the model or interfaces. > > > (on guest map/invalidate) -> IOAS_MAP(IOMAP_FIXED) to overmap part > > of > > > the reserved regions > > > (on dev hotplug) -> ATTACH (which might fail, if it conflicts with the > > > reserved regions) > > > (on vIOMMU reconfiguration) -> UNMAP/MAP reserved regions as > > > necessary (which might fail) > > > > OK, I will take care of it > > > > Thanks, > > Jason > -- 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: "Tian, Kevin" <kevin.tian@intel.com> Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>, Chaitanya Kulkarni <chaitanyak@nvidia.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>, Jason Wang <jasowang@redhat.com>, Cornelia Huck <cohuck@redhat.com>, Niklas Schnelle <schnelle@linux.ibm.com>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, Daniel Jordan <daniel.m.jordan@oracle.com>, Alex Williamson <alex.williamson@redhat.com>, Jason Gunthorpe <jgg@nvidia.com>, "Martins, Joao" <joao.m.martins@oracle.com> Subject: Re: [PATCH RFC 11/12] iommufd: vfio container FD ioctl compatibility Date: Fri, 13 May 2022 14:35:46 +1000 [thread overview] Message-ID: <Yn3gIiGLyHB/5kN4@yekko> (raw) In-Reply-To: <BN9PR11MB52765D95C6172ABE43E236A38CC89@BN9PR11MB5276.namprd11.prod.outlook.com> [-- Attachment #1.1: Type: text/plain, Size: 8026 bytes --] On Wed, May 11, 2022 at 03:15:22AM +0000, Tian, Kevin wrote: > > From: Jason Gunthorpe <jgg@nvidia.com> > > Sent: Wednesday, May 11, 2022 3:00 AM > > > > On Tue, May 10, 2022 at 05:12:04PM +1000, David Gibson wrote: > > > Ok... here's a revised version of my proposal which I think addresses > > > your concerns and simplfies things. > > > > > > - No new operations, but IOAS_MAP gets some new flags (and IOAS_COPY > > > will probably need matching changes) > > > > > > - By default the IOVA given to IOAS_MAP is a hint only, and the IOVA > > > is chosen by the kernel within the aperture(s). This is closer to > > > how mmap() operates, and DPDK and similar shouldn't care about > > > having specific IOVAs, even at the individual mapping level. > > > > > > - IOAS_MAP gets an IOMAP_FIXED flag, analagous to mmap()'s MAP_FIXED, > > > for when you really do want to control the IOVA (qemu, maybe some > > > special userspace driver cases) > > > > We already did both of these, the flag is called > > IOMMU_IOAS_MAP_FIXED_IOVA - if it is not specified then kernel will > > select the IOVA internally. > > > > > - ATTACH will fail if the new device would shrink the aperture to > > > exclude any already established mappings (I assume this is already > > > the case) > > > > Yes > > > > > - IOAS_MAP gets an IOMAP_RESERVE flag, which operates a bit like a > > > PROT_NONE mmap(). It reserves that IOVA space, so other (non-FIXED) > > > MAPs won't use it, but doesn't actually put anything into the IO > > > pagetables. > > > - Like a regular mapping, ATTACHes that are incompatible with an > > > IOMAP_RESERVEed region will fail > > > - An IOMAP_RESERVEed area can be overmapped with an IOMAP_FIXED > > > mapping > > > > Yeah, this seems OK, I'm thinking a new API might make sense because > > you don't really want mmap replacement semantics but a permanent > > record of what IOVA must always be valid. > > > > IOMMU_IOA_REQUIRE_IOVA perhaps, similar signature to > > IOMMUFD_CMD_IOAS_IOVA_RANGES: > > > > struct iommu_ioas_require_iova { > > __u32 size; > > __u32 ioas_id; > > __u32 num_iovas; > > __u32 __reserved; > > struct iommu_required_iovas { > > __aligned_u64 start; > > __aligned_u64 last; > > } required_iovas[]; > > }; > > As a permanent record do we want to enforce that once the required > range list is set all FIXED and non-FIXED allocations must be within the > list of ranges? No, I don't think so. In fact the way I was envisaging this, non-FIXED mappings will *never* go into the reserved ranges. This is for the benefit of any use cases that need both mappings where they don't care about the IOVA and those which do. Essentially, reserving a region here is saying to the kernel "I want to manage this IOVA space; make sure nothing else touches it". That means both that the kernel must disallow any hw associated changes (like ATTACH) which would impinge on the reserved region, and also any IOVA allocations that would take parts away from that space. Whether we want to restrict FIXED mappings to the reserved regions is an interesting question. I wasn't thinking that would be necessary (just as you can use mmap() MAP_FIXED anywhere). However.. much as MAP_FIXED is very dangerous to use if you don't previously reserve address space, I think IOMAP_FIXED is dangerous if you haven't previously reserved space. So maybe it would make sense to only allow FIXED mappings within reserved regions. Strictly dividing the IOVA space into kernel managed and user managed regions does make a certain amount of sense. > If yes we can take the end of the last range as the max size of the iova > address space to optimize the page table layout. > > otherwise we may need another dedicated hint for that optimization. Right. With the revised model where reserving windows is optional, not required, I don't think we can quite re-use this for optimization hints. Which is a bit unfortunate. I can't immediately see a way to tweak this which handles both more neatly, but I like the idea if we can figure out a way. > > > So, for DPDK the sequence would be: > > > > > > 1. Create IOAS > > > 2. ATTACH devices > > > 3. IOAS_MAP some stuff > > > 4. Do DMA with the IOVAs that IOAS_MAP returned > > > > > > (Note, not even any need for QUERY in simple cases) > > > > Yes, this is done already > > > > > For (unoptimized) qemu it would be: > > > > > > 1. Create IOAS > > > 2. IOAS_MAP(IOMAP_FIXED|IOMAP_RESERVE) the valid IOVA regions of > > the > > > guest platform > > > 3. ATTACH devices (this will fail if they're not compatible with the > > > reserved IOVA regions) > > > 4. Boot the guest > > I suppose above is only the sample flow for PPC vIOMMU. For non-PPC > vIOMMUs regular mappings are required before booting the guest and > reservation might be done but not mandatory (at least not what current > Qemu vfio can afford as it simply replays valid ranges in the CPU address > space). That was a somewhat simplified description. When we look in more detail, I think the ppc and x86 models become more similar. So, in more detail, I think it would look like this: 1. Create base IOAS 2. Map guest memory into base IOAS so that IOVA==GPA 3. Create IOASes for each vIOMMU domain 4. Reserve windows in domain IOASes where the vIOMMU will allow mappings by default 5. ATTACH devices to appropriate IOASes (***) 6. Boot the guest On guest map/invalidate: Use IOAS_COPY to take mappings from base IOAS and put them into the domain IOAS On memory hotplug: IOAS_MAP new memory block into base IOAS On dev hotplug: (***) ATTACH devices to appropriate IOAS On guest reconfiguration of vIOMMU domains (x86 only): DETACH device from base IOAS, attach to vIOMMU domain IOAS On guest reconfiguration of vIOMMU apertures (ppc only): Alter reserved regions to match vIOMMU The difference between ppc and x86 is at the places marked (***): which IOAS each device gets attached to and when. For x86 all devices live in the base IOAS by default, and only get moved to domain IOASes when those domains are set up in the vIOMMU. For POWER each device starts in a domain IOAS based on its guest PE, and never moves. [This is still a bit simplified. In practice, I imagine you'd optimize to only create the domain IOASes at the point they're needed - on boot for ppc, but only when the vIOMMU is configured for x86. I don't think that really changes the model, though.] A few aspects of the model interact quite nicely here. Mapping a large memory guest with IOVA==GPA would probably fail on a ppc host IOMMU. But if both guest and host are ppc, then no devices get attached to that base IOAS, so its apertures don't get restricted by the host hardware. That way we get a common model, and the benefits of GUP sharing via IOAS_COPY, without it failing in the ppc-on-ppc case. x86-on-ppc and ppc-on-x86 will probably only work in limited cases where the various sizes and windows line up, but the possibility isn't precluded by the model or interfaces. > > > (on guest map/invalidate) -> IOAS_MAP(IOMAP_FIXED) to overmap part > > of > > > the reserved regions > > > (on dev hotplug) -> ATTACH (which might fail, if it conflicts with the > > > reserved regions) > > > (on vIOMMU reconfiguration) -> UNMAP/MAP reserved regions as > > > necessary (which might fail) > > > > OK, I will take care of it > > > > Thanks, > > Jason > -- 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:[~2022-05-13 4:38 UTC|newest] Thread overview: 244+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-18 17:27 [PATCH RFC 00/12] IOMMUFD Generic interface Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-18 17:27 ` [PATCH RFC 01/12] interval-tree: Add a utility to iterate over spans in an interval tree Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-18 17:27 ` [PATCH RFC 02/12] iommufd: Overview documentation Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-18 17:27 ` [PATCH RFC 03/12] iommufd: File descriptor, context, kconfig and makefiles Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-22 14:18 ` Niklas Schnelle 2022-03-22 14:18 ` Niklas Schnelle 2022-03-22 14:50 ` Jason Gunthorpe 2022-03-22 14:50 ` Jason Gunthorpe via iommu 2022-03-18 17:27 ` [PATCH RFC 04/12] kernel/user: Allow user::locked_vm to be usable for iommufd Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-22 14:28 ` Niklas Schnelle 2022-03-22 14:28 ` Niklas Schnelle 2022-03-22 14:57 ` Jason Gunthorpe 2022-03-22 14:57 ` Jason Gunthorpe via iommu 2022-03-22 15:29 ` Alex Williamson 2022-03-22 15:29 ` Alex Williamson 2022-03-22 16:15 ` Jason Gunthorpe 2022-03-22 16:15 ` Jason Gunthorpe via iommu 2022-03-24 2:11 ` Tian, Kevin 2022-03-24 2:11 ` Tian, Kevin 2022-03-24 2:27 ` Jason Wang 2022-03-24 2:27 ` Jason Wang 2022-03-24 2:42 ` Tian, Kevin 2022-03-24 2:42 ` Tian, Kevin 2022-03-24 2:57 ` Jason Wang 2022-03-24 2:57 ` Jason Wang 2022-03-24 3:15 ` Tian, Kevin 2022-03-24 3:15 ` Tian, Kevin 2022-03-24 3:50 ` Jason Wang 2022-03-24 3:50 ` Jason Wang 2022-03-24 4:29 ` Tian, Kevin 2022-03-24 4:29 ` Tian, Kevin 2022-03-24 11:46 ` Jason Gunthorpe 2022-03-24 11:46 ` Jason Gunthorpe via iommu 2022-03-28 1:53 ` Jason Wang 2022-03-28 1:53 ` Jason Wang 2022-03-28 12:22 ` Jason Gunthorpe 2022-03-28 12:22 ` Jason Gunthorpe via iommu 2022-03-29 4:59 ` Jason Wang 2022-03-29 4:59 ` Jason Wang 2022-03-29 11:46 ` Jason Gunthorpe 2022-03-29 11:46 ` Jason Gunthorpe via iommu 2022-03-28 13:14 ` Sean Mooney 2022-03-28 13:14 ` Sean Mooney 2022-03-28 14:27 ` Jason Gunthorpe via iommu 2022-03-28 14:27 ` Jason Gunthorpe 2022-03-24 20:40 ` Alex Williamson 2022-03-24 20:40 ` Alex Williamson 2022-03-24 22:27 ` Jason Gunthorpe 2022-03-24 22:27 ` Jason Gunthorpe via iommu 2022-03-24 22:41 ` Alex Williamson 2022-03-24 22:41 ` Alex Williamson 2022-03-22 16:31 ` Niklas Schnelle 2022-03-22 16:31 ` Niklas Schnelle 2022-03-22 16:41 ` Jason Gunthorpe via iommu 2022-03-22 16:41 ` Jason Gunthorpe 2022-03-18 17:27 ` [PATCH RFC 05/12] iommufd: PFN handling for iopt_pages Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-23 15:37 ` Niklas Schnelle 2022-03-23 15:37 ` Niklas Schnelle 2022-03-23 16:09 ` Jason Gunthorpe 2022-03-23 16:09 ` Jason Gunthorpe via iommu 2022-03-18 17:27 ` [PATCH RFC 06/12] iommufd: Algorithms for PFN storage Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-18 17:27 ` [PATCH RFC 07/12] iommufd: Data structure to provide IOVA to PFN mapping Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-22 22:15 ` Alex Williamson 2022-03-22 22:15 ` Alex Williamson 2022-03-23 18:15 ` Jason Gunthorpe 2022-03-23 18:15 ` Jason Gunthorpe via iommu 2022-03-24 3:09 ` Tian, Kevin 2022-03-24 3:09 ` Tian, Kevin 2022-03-24 12:46 ` Jason Gunthorpe 2022-03-24 12:46 ` Jason Gunthorpe via iommu 2022-03-25 13:34 ` zhangfei.gao 2022-03-25 13:34 ` zhangfei.gao 2022-03-25 17:19 ` Jason Gunthorpe via iommu 2022-03-25 17:19 ` Jason Gunthorpe 2022-04-13 14:02 ` Yi Liu 2022-04-13 14:02 ` Yi Liu 2022-04-13 14:36 ` Jason Gunthorpe 2022-04-13 14:36 ` Jason Gunthorpe via iommu 2022-04-13 14:49 ` Yi Liu 2022-04-13 14:49 ` Yi Liu 2022-04-17 14:56 ` Yi Liu 2022-04-17 14:56 ` Yi Liu 2022-04-18 10:47 ` Yi Liu 2022-04-18 10:47 ` Yi Liu 2022-03-18 17:27 ` [PATCH RFC 08/12] iommufd: IOCTLs for the io_pagetable Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-23 19:10 ` Alex Williamson 2022-03-23 19:10 ` Alex Williamson 2022-03-23 19:34 ` Jason Gunthorpe 2022-03-23 19:34 ` Jason Gunthorpe via iommu 2022-03-23 20:04 ` Alex Williamson 2022-03-23 20:04 ` Alex Williamson 2022-03-23 20:34 ` Jason Gunthorpe via iommu 2022-03-23 20:34 ` Jason Gunthorpe 2022-03-23 22:54 ` Jason Gunthorpe 2022-03-23 22:54 ` Jason Gunthorpe via iommu 2022-03-24 7:25 ` Tian, Kevin 2022-03-24 7:25 ` Tian, Kevin 2022-03-24 13:46 ` Jason Gunthorpe via iommu 2022-03-24 13:46 ` Jason Gunthorpe 2022-03-25 2:15 ` Tian, Kevin 2022-03-25 2:15 ` Tian, Kevin 2022-03-27 2:32 ` Tian, Kevin 2022-03-27 2:32 ` Tian, Kevin 2022-03-27 14:28 ` Jason Gunthorpe 2022-03-27 14:28 ` Jason Gunthorpe via iommu 2022-03-28 17:17 ` Alex Williamson 2022-03-28 17:17 ` Alex Williamson 2022-03-28 18:57 ` Jason Gunthorpe 2022-03-28 18:57 ` Jason Gunthorpe via iommu 2022-03-28 19:47 ` Jason Gunthorpe via iommu 2022-03-28 19:47 ` Jason Gunthorpe 2022-03-28 21:26 ` Alex Williamson 2022-03-28 21:26 ` Alex Williamson 2022-03-24 6:46 ` Tian, Kevin 2022-03-24 6:46 ` Tian, Kevin 2022-03-30 13:35 ` Yi Liu 2022-03-30 13:35 ` Yi Liu 2022-03-31 12:59 ` Jason Gunthorpe via iommu 2022-03-31 12:59 ` Jason Gunthorpe 2022-04-01 13:30 ` Yi Liu 2022-04-01 13:30 ` Yi Liu 2022-03-31 4:36 ` David Gibson 2022-03-31 4:36 ` David Gibson 2022-03-31 5:41 ` Tian, Kevin 2022-03-31 5:41 ` Tian, Kevin 2022-03-31 12:58 ` Jason Gunthorpe via iommu 2022-03-31 12:58 ` Jason Gunthorpe 2022-04-28 5:58 ` David Gibson 2022-04-28 5:58 ` David Gibson 2022-04-28 14:22 ` Jason Gunthorpe 2022-04-28 14:22 ` Jason Gunthorpe via iommu 2022-04-29 6:00 ` David Gibson 2022-04-29 6:00 ` David Gibson 2022-04-29 12:54 ` Jason Gunthorpe 2022-04-29 12:54 ` Jason Gunthorpe via iommu 2022-04-30 14:44 ` David Gibson 2022-04-30 14:44 ` David Gibson 2022-03-18 17:27 ` [PATCH RFC 09/12] iommufd: Add a HW pagetable object Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-18 17:27 ` [PATCH RFC 10/12] iommufd: Add kAPI toward external drivers Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-23 18:10 ` Alex Williamson 2022-03-23 18:10 ` Alex Williamson 2022-03-23 18:15 ` Jason Gunthorpe 2022-03-23 18:15 ` Jason Gunthorpe via iommu 2022-05-11 12:54 ` Yi Liu 2022-05-11 12:54 ` Yi Liu 2022-05-19 9:45 ` Yi Liu 2022-05-19 9:45 ` Yi Liu 2022-05-19 12:35 ` Jason Gunthorpe 2022-05-19 12:35 ` Jason Gunthorpe via iommu 2022-03-18 17:27 ` [PATCH RFC 11/12] iommufd: vfio container FD ioctl compatibility Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-23 22:51 ` Alex Williamson 2022-03-23 22:51 ` Alex Williamson 2022-03-24 0:33 ` Jason Gunthorpe 2022-03-24 0:33 ` Jason Gunthorpe via iommu 2022-03-24 8:13 ` Eric Auger 2022-03-24 8:13 ` Eric Auger 2022-03-24 22:04 ` Alex Williamson 2022-03-24 22:04 ` Alex Williamson 2022-03-24 23:11 ` Jason Gunthorpe 2022-03-24 23:11 ` Jason Gunthorpe via iommu 2022-03-25 3:10 ` Tian, Kevin 2022-03-25 3:10 ` Tian, Kevin 2022-03-25 11:24 ` Joao Martins 2022-03-25 11:24 ` Joao Martins 2022-04-28 14:53 ` David Gibson 2022-04-28 14:53 ` David Gibson 2022-04-28 15:10 ` Jason Gunthorpe 2022-04-28 15:10 ` Jason Gunthorpe via iommu 2022-04-29 1:21 ` Tian, Kevin 2022-04-29 1:21 ` Tian, Kevin 2022-04-29 6:22 ` David Gibson 2022-04-29 6:22 ` David Gibson 2022-04-29 12:50 ` Jason Gunthorpe 2022-04-29 12:50 ` Jason Gunthorpe via iommu 2022-05-02 4:10 ` David Gibson 2022-05-02 4:10 ` David Gibson 2022-04-29 6:20 ` David Gibson 2022-04-29 6:20 ` David Gibson 2022-04-29 12:48 ` Jason Gunthorpe 2022-04-29 12:48 ` Jason Gunthorpe via iommu 2022-05-02 7:30 ` David Gibson 2022-05-02 7:30 ` David Gibson 2022-05-05 19:07 ` Jason Gunthorpe 2022-05-05 19:07 ` Jason Gunthorpe via iommu 2022-05-06 5:25 ` David Gibson 2022-05-06 5:25 ` David Gibson 2022-05-06 10:42 ` Tian, Kevin 2022-05-06 10:42 ` Tian, Kevin 2022-05-09 3:36 ` David Gibson 2022-05-09 3:36 ` David Gibson 2022-05-06 12:48 ` Jason Gunthorpe 2022-05-06 12:48 ` Jason Gunthorpe via iommu 2022-05-09 6:01 ` David Gibson 2022-05-09 6:01 ` David Gibson 2022-05-09 14:00 ` Jason Gunthorpe 2022-05-09 14:00 ` Jason Gunthorpe via iommu 2022-05-10 7:12 ` David Gibson 2022-05-10 7:12 ` David Gibson 2022-05-10 19:00 ` Jason Gunthorpe 2022-05-10 19:00 ` Jason Gunthorpe via iommu 2022-05-11 3:15 ` Tian, Kevin 2022-05-11 3:15 ` Tian, Kevin 2022-05-11 16:32 ` Jason Gunthorpe 2022-05-11 16:32 ` Jason Gunthorpe via iommu 2022-05-11 23:23 ` Tian, Kevin 2022-05-11 23:23 ` Tian, Kevin 2022-05-13 4:35 ` David Gibson [this message] 2022-05-13 4:35 ` David Gibson 2022-05-11 4:40 ` David Gibson 2022-05-11 4:40 ` David Gibson 2022-05-11 2:46 ` Tian, Kevin 2022-05-11 2:46 ` Tian, Kevin 2022-05-23 6:02 ` Alexey Kardashevskiy 2022-05-23 6:02 ` Alexey Kardashevskiy 2022-05-24 13:25 ` Jason Gunthorpe 2022-05-24 13:25 ` Jason Gunthorpe via iommu 2022-05-25 1:39 ` David Gibson 2022-05-25 1:39 ` David Gibson 2022-05-25 2:09 ` Alexey Kardashevskiy 2022-05-25 2:09 ` Alexey Kardashevskiy 2022-03-29 9:17 ` Yi Liu 2022-03-29 9:17 ` Yi Liu 2022-03-18 17:27 ` [PATCH RFC 12/12] iommufd: Add a selftest Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-04-12 20:13 ` [PATCH RFC 00/12] IOMMUFD Generic interface Eric Auger 2022-04-12 20:13 ` Eric Auger 2022-04-12 20:22 ` Jason Gunthorpe via iommu 2022-04-12 20:22 ` Jason Gunthorpe 2022-04-12 20:50 ` Eric Auger 2022-04-12 20:50 ` Eric Auger 2022-04-14 10:56 ` Yi Liu 2022-04-14 10:56 ` Yi Liu
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=Yn3gIiGLyHB/5kN4@yekko \ --to=david@gibson.dropbear.id.au \ --cc=alex.williamson@redhat.com \ --cc=baolu.lu@linux.intel.com \ --cc=chaitanyak@nvidia.com \ --cc=cohuck@redhat.com \ --cc=daniel.m.jordan@oracle.com \ --cc=eric.auger@redhat.com \ --cc=iommu@lists.linux-foundation.org \ --cc=jasowang@redhat.com \ --cc=jean-philippe@linaro.org \ --cc=jgg@nvidia.com \ --cc=joao.m.martins@oracle.com \ --cc=kevin.tian@intel.com \ --cc=kvm@vger.kernel.org \ --cc=mjrosato@linux.ibm.com \ --cc=mst@redhat.com \ --cc=nicolinc@nvidia.com \ --cc=schnelle@linux.ibm.com \ --cc=shameerali.kolothum.thodi@huawei.com \ --cc=yi.l.liu@intel.com \ --cc=zhukeqian1@huawei.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.