> From: Lu Baolu
> Sent: Tuesday, June 14, 2022 10:51 AM
>
> The domain_translation_struct debugfs node is used to dump the DMAR
> page
> tables for the PCI devices. It potentially races with setting domains to
> devices. The existing code uses a global spinlock device_domain_lock to
> avoid the
> From: Lu Baolu
> Sent: Tuesday, June 14, 2022 10:51 AM
>
> The disable_dmar_iommu() is called when IOMMU initialization fails or
> the IOMMU is hot-removed from the system. In both cases, there is no
> need to clear the IOMMU translation data structures for devices.
>
> On the initialization p
> From: Lu Baolu
> Sent: Tuesday, June 14, 2022 10:52 AM
>
> The iommu->lock is used to protect the per-IOMMU domain ID resource.
> Moving the lock into the ID alloc/free helpers makes the code more
> compact. At the same time, the device_domain_lock is irrelevant to
> the domain ID resource, rem
> From: Lu Baolu
> Sent: Tuesday, June 14, 2022 10:52 AM
>
> The iommu->lock is used to protect changes in root/context/pasid tables
> and domain ID allocation. There's no use case to change these resources
> in any interrupt context. Hence there's no need to disable interrupts
> when helding the
> From: Lu Baolu
> Sent: Tuesday, June 14, 2022 10:52 AM
>
> When the IOMMU domain is about to be freed, it should not be set on any
> device. Instead of silently dealing with some bug cases, it's better to
> trigger a warning to report and fix any potential bugs at the first time.
>
> Signed-of
> From: Lu Baolu
> Sent: Tuesday, June 14, 2022 10:52 AM
>
> Fold __dmar_remove_one_dev_info() into dmar_remove_one_dev_info()
> which
> is its only caller. Make the spin lock critical range only cover the
> device list change code and remove some unnecessary checks.
>
> Signed-off-by: Lu Baolu
> From: Lu Baolu
> Sent: Tuesday, June 14, 2022 10:52 AM
>
> The device_domain_lock is used to protect the device tracking list of
> a domain. Remove unnecessary spin_lock/unlock()'s and move the necessary
> ones around the list access.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel/i
> From: Baolu Lu
> Sent: Tuesday, June 14, 2022 2:13 PM
>
> On 2022/6/14 13:36, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Tuesday, June 14, 2022 12:48 PM
> >>
> >> On 2022/6/14 12:02, Tian, Kevin wrote:
> >>>> From: Lu Baolu
> From: Baolu Lu
> Sent: Wednesday, June 15, 2022 9:54 AM
>
> On 2022/6/14 14:43, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Tuesday, June 14, 2022 10:51 AM
> >>
> >> The domain_translation_struct debugfs node is used to dump the DM
> From: Baolu Lu
> Sent: Tuesday, June 14, 2022 3:21 PM
>
> On 2022/6/14 14:49, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Tuesday, June 14, 2022 10:51 AM
> >>
> >> The disable_dmar_iommu() is called when IOMMU initialization fails or
> &
> From: Nicolin Chen
> Sent: Wednesday, June 15, 2022 4:45 AM
>
> Hi Kevin,
>
> On Wed, Jun 08, 2022 at 11:48:27PM +, Tian, Kevin wrote:
> > > > > The KVM mechanism for controlling wbinvd is only triggered during
> > > > > kvm_vfio_group_ad
> From: Baolu Lu
> Sent: Wednesday, June 15, 2022 9:10 PM
>
> On 2022/6/15 14:22, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Tuesday, June 14, 2022 3:21 PM
> >>
> >> On 2022/6/14 14:49, Tian, Kevin wrote:
> >>>&
> From: Nicolin Chen
> Sent: Thursday, June 16, 2022 8:03 AM
>
> Cases like VFIO wish to attach a device to an existing domain that was
> not allocated specifically from the device. This raises a condition
> where the IOMMU driver can fail the domain attach because the domain and
> device are inc
> From: Nicolin Chen
> Sent: Thursday, June 16, 2022 8:03 AM
>
> From: Jason Gunthorpe
>
> The KVM mechanism for controlling wbinvd is based on OR of the coherency
> property of all devices attached to a guest, no matter those devices are
> attached to a single domain or multiple domains.
>
>
> From: Nicolin Chen
> Sent: Thursday, June 16, 2022 8:03 AM
>
> The domain->ops validation was added, as a precaution, for mixed-driver
> systems. However, at this moment only one iommu driver is possible. So
> remove it.
It's true on a physical platform. But I'm not sure whether a virtual plat
> From: Nicolin Chen
> Sent: Thursday, June 16, 2022 8:03 AM
>
> All devices in emulated_iommu_groups have pinned_page_dirty_scope
> set, so the update_dirty_scope in the first list_for_each_entry
> is always false. Clean it up, and move the "if update_dirty_scope"
> part from the detach_group_don
> From: Nicolin Chen
> Sent: Thursday, June 16, 2022 8:03 AM
>
> Un-inline the domain specific logic from the attach/detach_group ops into
> two paired functions vfio_iommu_alloc_attach_domain() and
> vfio_iommu_detach_destroy_domain() that strictly deal with creating and
> destroying struct vfio_
> From: Nicolin Chen
> Sent: Friday, June 17, 2022 6:41 AM
>
> > ...
> > > - if (resv_msi) {
> > > + if (resv_msi && !domain->msi_cookie) {
> > > ret = iommu_get_msi_cookie(domain->domain,
> > > resv_msi_base);
> > > if (ret && ret != -ENODEV)
> > >
> From: Baolu Lu
> Sent: Friday, June 10, 2022 3:16 PM
> >
> >> +#define __IOMMU_DOMAIN_HOST_VA(1U << 5) /* Host CPU virtual
> address */
> >
> > Do you mean general CPU VA? or Host CPU VA, I'm reading the latter as
> 2nd
> > stage?
>
> Host CPU VA. In the near future, we will add another fla
> From: Lu Baolu
> Sent: Tuesday, June 7, 2022 9:50 AM
>
> +
> +static const struct iommu_domain_ops intel_svm_domain_ops = {
> + .set_dev_pasid = intel_svm_attach_dev_pasid,
> + .block_dev_pasid= intel_svm_detach_dev_pasid,
> + .free = intel_svm_dom
> From: Lu Baolu
> Sent: Monday, June 20, 2022 4:17 PM
> @@ -2564,7 +2564,7 @@ static int domain_add_dev_info(struct
> dmar_domain *domain, struct device *dev)
> ret = intel_pasid_setup_second_level(iommu,
> domain,
> dev, PASID_RID2PASID
> From: Baolu Lu
> Sent: Tuesday, June 21, 2022 11:39 AM
>
> On 2022/6/21 10:54, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Monday, June 20, 2022 4:17 PM
> >> @@ -2564,7 +2564,7 @@ static int domain_add_dev_info(struct
>
> From: Baolu Lu
> Sent: Tuesday, June 21, 2022 12:28 PM
>
> On 2022/6/21 11:46, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Tuesday, June 21, 2022 11:39 AM
> >>
> >> On 2022/6/21 10:54, Tian, Kevin wrote:
> >>>> From: Lu Baol
> From: Baolu Lu
> Sent: Tuesday, June 21, 2022 5:04 PM
>
> On 2022/6/21 13:48, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Tuesday, June 21, 2022 12:28 PM
> >>
> >> On 2022/6/21 11:46, Tian, Kevin wrote:
> >>>> From: Baolu Lu
> From: Baolu Lu
> Sent: Wednesday, June 22, 2022 11:28 AM
>
> On 2022/6/22 11:06, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Tuesday, June 21, 2022 5:04 PM
> >>
> >> On 2022/6/21 13:48, Tian, Kevin wrote:
> >>>> From: Baolu L
> From: Lu Baolu
> Sent: Wednesday, June 22, 2022 12:41 PM
>
> The IOMMU driver shares the pasid table for PCI alias devices. When the
> RID2PASID entry of the shared pasid table has been filled by the first
> device, the subsequent devices will encounter the "DMAR: Setup RID2PASID
> failed" fail
> From: Robin Murphy
> Sent: Wednesday, June 22, 2022 3:55 PM
>
> On 2022-06-16 23:23, Nicolin Chen wrote:
> > On Thu, Jun 16, 2022 at 06:40:14AM +, Tian, Kevin wrote:
> >
> >>> The domain->ops validation was added, as a precaution, for mixed-
> dri
> From: Alex Williamson
> Sent: Thursday, June 23, 2022 6:17 AM
>
> >
> > ret = -EIO;
> > - domain->domain = iommu_domain_alloc(bus);
> > + domain->domain = iommu_domain_alloc(iommu_api_dev->dev-
> >bus);
>
> It makes sense to move away from a bus centric interface to iommu ops
> and I c
> From: Yong Wu
> Sent: Friday, June 24, 2022 1:39 PM
>
> On Thu, 2022-06-23 at 19:44 -0700, Nicolin Chen wrote:
> > On Fri, Jun 24, 2022 at 09:35:49AM +0800, Baolu Lu wrote:
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On 2022/6/24 04:00, Nicolin Chen wrote:
>
> From: Lu Baolu
> Sent: Thursday, June 23, 2022 2:57 PM
>
> The IOMMU driver shares the pasid table for PCI alias devices. When the
> RID2PASID entry of the shared pasid table has been filled by the first
> device, the subsequent device will encounter the "DMAR: Setup RID2PASID
> failed" failure
> From: Nicolin Chen
> Sent: Friday, June 24, 2022 4:00 AM
>
> Un-inline the domain specific logic from the attach/detach_group ops into
> two paired functions vfio_iommu_alloc_attach_domain() and
> vfio_iommu_detach_destroy_domain() that strictly deal with creating and
> destroying struct vfio_d
> From: Robin Murphy
> Sent: Saturday, June 25, 2022 1:52 AM
>
> Since IOMMU groups are mandatory for drivers to support, it stands to
> reason that any device which has been successfully added to a group
> must be on a bus supported by that IOMMU driver, and therefore a domain
> viable for any de
> From: Robin Murphy
> Sent: Saturday, June 25, 2022 2:00 AM
>
> Use the new interface to check the capabilities for our device
> specifically.
>
> Reviewed-by: Lu Baolu
> Signed-off-by: Robin Murphy
Reviewed-by: Kevin Tian
___
iommu mailing list
io
> From: Lu Baolu
> Sent: Tuesday, June 21, 2022 10:44 PM
>
> Use this field to keep the number of supported PASIDs that an IOMMU
> hardware is able to support. This is a generic attribute of an IOMMU
> and lifting it into the per-IOMMU device structure makes it possible
> to allocate a PASID for
> From: Lu Baolu
> Sent: Tuesday, June 21, 2022 10:44 PM
>
> Use this field to save the number of PASIDs that a device is able to
> consume. It is a generic attribute of a device and lifting it into the
> per-device dev_iommu struct could help to avoid the boilerplate code
> in various IOMMU driv
> From: Lu Baolu
> Sent: Tuesday, June 21, 2022 10:44 PM
>
> The sva iommu_domain represents a hardware pagetable that the IOMMU
> hardware could use for SVA translation. This adds some infrastructure
> to support SVA domain in the iommu common layer. It includes:
>
> - Extend the iommu_domain t
> From: Lu Baolu
> Sent: Tuesday, June 21, 2022 10:44 PM
>
> Add support for SVA domain allocation and provide an SVA-specific
> iommu_domain_ops.
>
> Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
___
iommu mailing list
iommu@lists.linux-foundatio
> From: Lu Baolu
> Sent: Tuesday, June 21, 2022 10:44 PM
> +struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct
> mm_struct *mm)
> +{
> + struct iommu_domain *domain;
> + ioasid_t max_pasids;
> + int ret = -EINVAL;
> +
> + /* Allocate mm->pasid if necessary. */
this
> From: Lu Baolu
> Sent: Tuesday, June 21, 2022 10:44 PM
> +/*
> + * I/O page fault handler for SVA
> + */
> +enum iommu_page_response_code
> +iommu_sva_handle_iopf(struct iommu_fault *fault, void *data)
> +{
> + vm_fault_t ret;
> + struct mm_struct *mm;
> + struct vm_area_struct *vma;
> From: Lu Baolu
> Sent: Tuesday, June 21, 2022 10:44 PM
>
> Tweak the I/O page fault handling framework to route the page faults to
> the domain and call the page fault handler retrieved from the domain.
> This makes the I/O page fault handling framework possible to serve more
> usage scenarios
> From: Lu Baolu
> Sent: Tuesday, June 21, 2022 10:44 PM
>
> Rename iommu-sva-lib.c[h] to iommu-sva.c[h] as it contains all code
> for SVA implementation in iommu core.
>
> Signed-off-by: Lu Baolu
> Reviewed-by: Jean-Philippe Brucker
Reviewed-by: Kevin Tian
__
> From: Baolu Lu
> Sent: Tuesday, June 28, 2022 1:41 PM
> >
> >> struct iommu_domain {
> >>unsigned type;
> >>const struct iommu_domain_ops *ops;
> >>unsigned long pgsize_bitmap;/* Bitmap of page sizes in use */
> >> - iommu_fault_handler_t handler;
> >> - void *handler_token;
> From: Baolu Lu
> Sent: Tuesday, June 28, 2022 1:54 PM
> >> +u32 iommu_sva_get_pasid(struct iommu_sva *handle)
> >> +{
> >> + struct iommu_domain *domain =
> >> + container_of(handle, struct iommu_domain, bond);
> >> +
> >> + return domain->mm->pasid;
> >> +}
> >> +EXPORT_SYMBO
> From: Jean-Philippe Brucker
> Sent: Tuesday, June 28, 2022 5:44 PM
>
> On Tue, Jun 28, 2022 at 08:39:36AM +, Tian, Kevin wrote:
> > > From: Lu Baolu
> > > Sent: Tuesday, June 21, 2022 10:44 PM
> > >
> > > Tweak the I/O page fault handling
> From: Baolu Lu
> Sent: Tuesday, June 28, 2022 7:34 PM
>
> On 2022/6/28 16:50, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Tuesday, June 28, 2022 1:41 PM
> >>>>struct iommu_domain {
> >>>> unsig
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> It is not used anywhere. Remove it to avoid dead code.
>
> Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfounda
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> @@ -1062,11 +1040,14 @@ static int alloc_iommu(struct dmar_drhd_unit
> *drhd)
> if (!iommu)
> return -ENOMEM;
>
> - if (dmar_alloc_seq_id(iommu) < 0) {
> + iommu->seq_id = ida_alloc_range(&dmar_seq_ids, 0,
>
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> +struct iommu_domain_info {
> + struct intel_iommu *iommu;
> + unsigned int refcnt;
> + u16 did;
> +};
> +
> struct dmar_domain {
> int nid;/* node id */
> -
> - unsigned int iommu_refcnt[D
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> In the IOMMU hot-add path, there's a need to check whether an IOMMU
> has been probed. Instead of checking the IOMMU pointer in the global
> list, it's better to allocate a flag bit in iommu->flags for this
> purpose.
Sorry I didn't ge
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> The g_iommus is not used anywhere. Remove it to avoid dead code.
>
> Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.l
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> If the available hardware exceeds DMAR_UNITS_SUPPORTED (previously set
> to MAX_IO_APICS, or 128), it causes these messages: "DMAR: Failed to
> allocate seq_id", "DMAR: Parse DMAR table failure.", and "x2apic: IRQ
> remapping doesn't su
> From: Robin Murphy
> Sent: Thursday, June 30, 2022 4:22 PM
>
> On 2022-06-29 20:47, Nicolin Chen wrote:
> > On Fri, Jun 24, 2022 at 03:19:43PM -0300, Jason Gunthorpe wrote:
> >> On Fri, Jun 24, 2022 at 06:35:49PM +0800, Yong Wu wrote:
> >>
> > It's not used in VFIO context. "return 0" just
> From: Alexey Kardashevskiy
> Sent: Friday, July 1, 2022 12:58 PM
>
> On 4/8/22 01:23, Jason Gunthorpe via iommu wrote:
> > IOMMU_CACHE means that normal DMAs do not require any additional
> coherency
> > mechanism and is the basic uAPI that VFIO exposes to userspace. For
> > instance VFIO appli
> From: Baolu Lu
> Sent: Friday, July 1, 2022 11:13 AM
>
> On 6/30/22 4:29 PM, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Saturday, June 25, 2022 8:52 PM
> >>
> >> In the IOMMU hot-add path, there's a need to check whether an IOMM
> From: Lu Baolu
> Sent: Wednesday, June 29, 2022 3:47 PM
>
> v3:
> - Split reduction of lock ranges from changing irqsave.
>https://lore.kernel.org/linux-
> iommu/BN9PR11MB52760A3D7C6BF1AF9C9D34658CAA9@BN9PR11MB5276.
> namprd11.prod.outlook.com/
> - Fully initialize the dev_info before add
> From: Lu Baolu
> Sent: Wednesday, June 29, 2022 3:47 PM
>
> The domain_translation_struct debugfs node is used to dump the DMAR
> page
> tables for the PCI devices. It potentially races with setting domains to
> devices. The existing code uses the global spinlock device_domain_lock to
> avoid t
> From: Lu Baolu
> Sent: Wednesday, June 29, 2022 3:47 PM
>
> The disable_dmar_iommu() is called when IOMMU initialization fails or
> the IOMMU is hot-removed from the system. In both cases, there is no
> need to clear the IOMMU translation data structures for devices.
>
> On the initialization
> From: Lu Baolu
> Sent: Wednesday, June 29, 2022 3:47 PM
>
> The iommu->lock is used to protect the per-IOMMU domain ID resource.
> Moving the lock into the ID alloc/free helpers makes the code more
> compact. At the same time, the device_domain_lock is irrelevant to
> the domain ID resource, re
> From: Lu Baolu
> Sent: Wednesday, June 29, 2022 3:47 PM
>
> Fold __dmar_remove_one_dev_info() into dmar_remove_one_dev_info()
> which
> is its only caller. Make the spin lock critical range only cover the
> device list change code and remove some unnecessary checks.
>
> Signed-off-by: Lu Baolu
> From: Lu Baolu
> Sent: Wednesday, June 29, 2022 3:47 PM
>
> + spin_lock_irqsave(&device_domain_lock, flags);
> list_for_each_entry(info, &domain->devices, link) {
> - if (!info->dev)
> - continue;
> -
suppose you can replace all spin_lock_irqsave() wit
> From: Lu Baolu
> Sent: Wednesday, June 29, 2022 3:47 PM
>
> Using a global device_domain_lock spinlock to protect per-domain device
> tracking lists is an inefficient way, especially considering this lock
> is also needed in the hot paths. This optimizes the locking mechanism
> by converting th
> From: Song Bao Hua (Barry Song)
> Sent: Tuesday, January 26, 2021 9:27 AM
>
> > -Original Message-
> > From: Jason Gunthorpe [mailto:j...@ziepe.ca]
> > Sent: Tuesday, January 26, 2021 2:13 PM
> > To: Song Bao Hua (Barry Song)
> > Cc: Wangzhou (B) ; Greg Kroah-Hartman
> > ; Arnd Bergmann
> From: Jason Gunthorpe
> Sent: Tuesday, February 2, 2021 7:44 AM
>
> On Fri, Jan 29, 2021 at 10:09:03AM +, Tian, Kevin wrote:
> > > SVA is not doom to work with IO page fault only. If we have SVA+pin,
> > > we would get both sharing address and stable I/O la
> From: Lu Baolu
> Sent: Wednesday, February 3, 2021 5:33 PM
>
> From: Yian Chen
>
> Starting from Intel VT-d v3.2, Intel platform BIOS can provide a new SATC
> table structure. SATC table lists a set of SoC integrated devices that
> require ATC to work (VT-d specification v3.2, section 8.8). Fu
742.18840-1-
> zhukeqi...@huawei.com/
Thanks for the pointer. We will take a look.
>
> On 2020/5/27 17:14, Jean-Philippe Brucker wrote:
> > On Wed, May 27, 2020 at 08:40:47AM +, Tian, Kevin wrote:
> >>> From: Xiang Zheng
> >>> Sent: Wednesday, May 27, 2020 2:
> From: Jacob Pan
> Sent: Friday, February 19, 2021 5:31 AM
>
> Write protect bit, when set, inhibits supervisor writes to the read-only
> pages. In guest supervisor shared virtual addressing (SVA), write-protect
> should be honored upon guest bind supervisor PASID request.
>
> This patch extend
> From: Jacob Pan
> Sent: Saturday, February 20, 2021 1:09 AM
>
> Hi Kevin,
>
> On Fri, 19 Feb 2021 06:19:04 +, "Tian, Kevin"
> wrote:
>
> > > From: Jacob Pan
> > > Sent: Friday, February 19, 2021 5:31 AM
> > >
> > &g
> From: Jacob Pan
> Sent: Thursday, March 4, 2021 2:29 AM
>
> Hi Vivek,
>
> On Fri, 15 Jan 2021 17:43:39 +0530, Vivek Gautam
> wrote:
>
> > From: Jean-Philippe Brucker
> >
> > Add support for tlb invalidation ops that can send invalidation
> > requests to back-end virtio-iommu when stage-1 pa
> From: iommu On Behalf Of
> Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
>
> > 2. Consider ensuring that the problem is not somehow related to queued
> > invalidations. Try to use __iommu_flush_iotlb() instead of qi_flush_iotlb().
> >
>
> I tried to force to use __iommu_flush_iot
> From: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
>
>
>
> > -Original Message-----
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: Thursday, March 18, 2021 4:27 PM
> > To: Longpeng (Mike, Cloud Infrastructure Service Pro
> From: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
>
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: Thursday, March 18, 2021 4:27 PM
> > To: Longpeng (Mike, Cloud Infrastructure Service Produc
> From: Auger Eric
> Sent: Monday, March 15, 2021 3:52 PM
> To: Christoph Hellwig
> Cc: k...@vger.kernel.org; Will Deacon ; linuxppc-
> d...@lists.ozlabs.org; dri-de...@lists.freedesktop.org; Li Yang
> ; iommu@lists.linux-foundation.org;
>
> Hi Christoph,
>
> On 3/14/21 4:58 PM, Christoph Hellwi
> From: Jason Gunthorpe
> Sent: Tuesday, March 30, 2021 12:32 AM
>
> On Wed, Mar 24, 2021 at 12:05:28PM -0700, Jacob Pan wrote:
>
> > > IMHO a use created PASID is either bound to a mm (current) at creation
> > > time, or it will never be bound to a mm and its page table is under
> > > user cont
> From: Jason Gunthorpe
> Sent: Tuesday, March 30, 2021 12:32 AM
> > In terms of usage for guest SVA, an ioasid_set is mostly tied to a host mm,
> > the use case is as the following:
>
> From that doc:
>
> It is imperative to enforce
> VM-IOASID ownership such that a malicious guest cannot t
> From: Tian, Kevin
> Sent: Tuesday, March 30, 2021 10:24 AM
>
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 30, 2021 12:32 AM
> > > In terms of usage for guest SVA, an ioasid_set is mostly tied to a host
> > > mm,
> > > the use case is as th
> From: Jason Gunthorpe
> Sent: Friday, April 2, 2021 12:04 AM
>
> On Thu, Apr 01, 2021 at 02:08:17PM +, Liu, Yi L wrote:
>
> > DMA page faults are delivered to root-complex via page request message
> and
> > it is per-device according to PCIe spec. Page request handling flow is:
> >
> > 1)
> From: Jason Gunthorpe
> Sent: Thursday, April 1, 2021 9:47 PM
>
> On Thu, Apr 01, 2021 at 01:43:36PM +, Liu, Yi L wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, April 1, 2021 9:16 PM
> > >
> > > On Thu, Apr 01, 2021 at 01:10:48PM +, Liu, Yi L wrote:
> > > > > From: Jason Gunt
> From: Jason Gunthorpe
> Sent: Tuesday, March 30, 2021 9:29 PM
>
> >
> > First, userspace may use ioasid in a non-SVA scenario where ioasid is
> > bound to specific security context (e.g. a control vq in vDPA) instead of
> > tying to mm. In this case there is no pgtable binding initiated from us
> From: Tian, Kevin
> Sent: Friday, April 2, 2021 3:58 PM
>
> > From: Jason Gunthorpe
> > Sent: Thursday, April 1, 2021 9:47 PM
> >
> > On Thu, Apr 01, 2021 at 01:43:36PM +, Liu, Yi L wrote:
> > > > From: Jason Gunthorpe
> > > > Sen
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 7:35 AM
>
> On Fri, Apr 02, 2021 at 07:30:23AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Friday, April 2, 2021 12:04 AM
> > >
> > > On Thu, Apr 01, 2021 at 02:08:17P
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 7:40 AM
>
> On Fri, Apr 02, 2021 at 07:58:02AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, April 1, 2021 9:47 PM
> > >
> > > On Thu, Apr 01, 2021 at 01:43:36
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 7:43 AM
>
> On Fri, Apr 02, 2021 at 08:22:28AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, March 30, 2021 9:29 PM
> > >
> > > >
> > > > First,
> From: Tian, Kevin
> Sent: Tuesday, April 6, 2021 9:02 AM
>
> > From: Jason Gunthorpe
> > Sent: Tuesday, April 6, 2021 7:40 AM
> >
> > On Fri, Apr 02, 2021 at 07:58:02AM +, Tian, Kevin wrote:
> > > > From: Jason Gunthorpe
> > > > Sen
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 8:35 PM
>
> On Tue, Apr 06, 2021 at 01:27:15AM +, Tian, Kevin wrote:
> >
> > and here is one example why using existing VFIO/VDPA interface makes
> > sense. say dev1 (w/ sva) and dev2 (w/o sva) are placed
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 8:21 PM
>
> On Tue, Apr 06, 2021 at 01:02:05AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, April 6, 2021 7:40 AM
> > >
> > > On Fri, Apr 02, 2021 at 07:58:02AM
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 8:43 PM
>
> On Tue, Apr 06, 2021 at 09:35:17AM +0800, Jason Wang wrote:
>
> > > VFIO and VDPA has no buisness having map/unmap interfaces once we
> have
> > > /dev/ioasid. That all belongs in the iosaid side.
> > >
> > > I know they have thos
> From: Jason Gunthorpe
> Sent: Wednesday, April 7, 2021 8:21 PM
>
> On Wed, Apr 07, 2021 at 02:08:33AM +, Tian, Kevin wrote:
>
> > > Because if you don't then we enter insane world where a PASID is being
> > > created under /dev/ioasid but it
> From: Jason Gunthorpe
> Sent: Thursday, April 22, 2021 7:03 AM
>
> > The pseudo code above really suggests you do want to remove
> > /dev/vfio/vfio, but this is only one of the IOMMU backends for vfio, so
> > I can't quite figure out if we're talking past each other.
>
> I'm not quite sure wha
> From: Jason Gunthorpe
> Sent: Thursday, April 22, 2021 8:10 PM
>
> On Thu, Apr 22, 2021 at 08:34:32AM +, Tian, Kevin wrote:
>
> > Another tricky thing is that a container may be linked to multiple iommu
> > domains in VFIO, as devices in the container
> From: Jason Gunthorpe
> Sent: Friday, April 23, 2021 7:40 AM
>
> On Thu, Apr 22, 2021 at 04:38:08PM -0600, Alex Williamson wrote:
>
> > Because it's fundamental to the isolation of the device? What you're
> > proposing doesn't get around the group issue, it just makes it implicit
> > rather t
> From: Jason Gunthorpe
> Sent: Friday, April 23, 2021 7:50 PM
>
> On Fri, Apr 23, 2021 at 09:06:44AM +, Tian, Kevin wrote:
>
> > Or could we still have just one /dev/ioasid but allow userspace to create
> > multiple gpa_ioasid_id's each associated to a diff
> From: Jason Gunthorpe
> Sent: Monday, April 26, 2021 8:38 PM
>
[...]
> > Want to hear your opinion for one open here. There is no doubt that
> > an ioasid represents a HW page table when the table is constructed by
> > userspace and then linked to the IOMMU through the bind/unbind
> > API. But
> From: Jason Gunthorpe
> Sent: Wednesday, April 28, 2021 1:12 AM
>
[...]
> > As Alex says, if this line fails because of the group restrictions,
> > that's not great because it's not very obvious what's gone wrong.
>
> Okay, that is fair, but let's solve that problem directly. For
> instance n
> From: Jason Gunthorpe
> Sent: Wednesday, April 28, 2021 1:12 AM
>
[...]
> One option is VFIO can keep its group FD but nothing else will have
> anthing like it. However I don't much like the idea that VFIO will
> have a special and unique programming model to do that same things
> other subsyst
> From: Alex Williamson
> Sent: Wednesday, April 28, 2021 11:06 PM
>
> On Wed, 28 Apr 2021 06:34:11 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jason Gunthorpe
> > > Sent: Monday, April 26, 2021 8:38 PM
> > >
> > [...]
> > >
> From: Jason Gunthorpe
> Sent: Wednesday, May 5, 2021 1:13 AM
>
> On Wed, Apr 28, 2021 at 06:58:19AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, April 28, 2021 1:12 AM
> > >
> > [...]
> > > > As Alex s
> From: Jason Gunthorpe
> Sent: Thursday, April 29, 2021 4:46 AM
>
> > > I think the name IOASID is fine for the uAPI, the kernel version can
> > > be called ioasid_id or something.
> >
> > ioasid is already an id and then ioasid_id just adds confusion. Another
> > point is that ioasid is current
> From: Jason Gunthorpe
> Sent: Saturday, May 8, 2021 1:11 AM
>
> On Fri, May 07, 2021 at 11:06:14AM -0600, Alex Williamson wrote:
>
> > We had tossed around an idea of a super-container with vfio, it's maybe
> > something we'd want to incorporate into this design. For instance, if
> > memory co
> From: Alex Williamson
> Sent: Saturday, May 8, 2021 1:06 AM
>
> > > Those are the main ones I can think of. It is nice to have a simple
> > > map/unmap interface, I'd hope that a new /dev/ioasid interface wouldn't
> > > raise the barrier to entry too high, but the user needs to have the
> > >
> From: Raj, Ashok
> Sent: Friday, May 7, 2021 12:33 AM
>
> > Basically it means when the guest's top level IOASID is created for
> > nesting that IOASID claims all PASID's on the RID and excludes any
> > PASID IOASIDs from existing on the RID now or in future.
>
> The way to look at it this is
401 - 500 of 784 matches
Mail list logo
