> From: Baolu Lu
> Sent: Wednesday, October 9, 2024 9:09 AM
>
> On 2024/9/30 15:19, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Friday, September 13, 2024 10:17 AM
> >>
> >> On 9/13/24 9:35 AM, Baolu Lu wrote:
> >&g
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:17 PM
>
> PASID usage requires PASID support in both device and IOMMU. Since the
> iommu drivers always enable the PASID capability for the device if it
> is supported, so it is reasonable to extend the IOMMU_GET_HW_INFO to
> report the PAS
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:17 PM
>
> +/*
> + * VFIO_DEVICE_PASID_ATTACH_IOMMUFD_PT - _IOW(VFIO_TYPE,
> VFIO_BASE + 21,
> + * struct
> vfio_device_pasid_attach_iommufd_pt)
> + * @argsz: User filled size of this data.
> + * @fl
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:17 PM
>
> There is no helpers for user to check if a given ID is allocated or not,
> neither a helper to loop all the allocated IDs in an IDA and do something
> for cleanup. With the two needs, a helper to get the lowest allocated ID
> of a
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:13 PM
>
> The iommu_attach_handle is optional in the RID attach/replace API and the
> PASID attach APIs. But it is a mandatory argument for the PASID replace API.
> Without it, the PASID replace path cannot get the old domain. Hence, the
>
> From: Yi Liu
> Sent: Thursday, September 12, 2024 9:13 PM
>
> iommufd plans to always pass in an iommu_attach_handle to the iommu
> core, so it's no longer fault specific, hence move the helpers out
> of the fault.c
again please put the reason for why iommufd plans to do so.
> --- a/drivers/i
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:13 PM
>
> @@ -191,13 +187,25 @@ int iommufd_fault_domain_replace_dev(struct
> iommufd_device *idev,
> return ret;
> }
>
> - ret = __fault_domain_replace_dev(idev, hwpt, old);
> + if (hwpt->fault) {
> +
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:13 PM
>
> +/**
> + * iommu_replace_device_pasid - Replace the domain that a pasid is
> attached to
> + * @domain: the new iommu domain
> + * @dev: the attached device.
> + * @pasid: the pasid of the device.
> + * @handle: the attach handle.
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:07 PM
>
> The iommu drivers are on the way to drop the remove_dev_pasid op by
> extending the blocked_domain to support PASID. However, this cannot be
> done in one shot. So far, the Intel iommu and the ARM SMMUv3 driver have
> supported it
> From: Yi Liu
> Sent: Thursday, September 12, 2024 9:07 PM
>
> The blocked domain can be extended to park PASID of a device to be the
> DMA blocking state. By this the remove_dev_pasid() op is dropped.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:07 PM
>
> From: Jason Gunthorpe
>
> The blocked domain is used to park RID to be blocking DMA state. This
> can be extended to PASID as well. By this, the remove_dev_pasid() op
> of ARM SMMUv3 can be dropped.
>
> Signed-off-by: Jason Gun
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:04 PM
>
> The iommu core is going to support domain replacement for pasid, it needs
> to make the set_dev_pasid op support replacing domain and keep the old
> domain config in the failure case.
>
> AMD iommu driver does not support domain
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:04 PM
>
> From: Jason Gunthorpe
>
> set_dev_pasid() op is going to be enhanced to support domain replacement
> of a pasid. This prepares for this op definition.
>
> Signed-off-by: Jason Gunthorpe
> Signed-off-by: Yi Liu
Reviewed-by: K
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:04 PM
>
> From: Lu Baolu
>
> Extend intel_iommu_set_dev_pasid() to set a nested type domain to a PASID
> of a device.
>
> Signed-off-by: Lu Baolu
> Co-developed-by: Yi Liu
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Baolu Lu
> Sent: Friday, September 13, 2024 10:17 AM
>
> On 9/13/24 9:35 AM, Baolu Lu wrote:
> > On 9/12/24 9:04 PM, Yi Liu wrote:
> >> +static void intel_iommu_remove_dev_pasid(struct device *dev, ioasid_t
> >> pasid,
> >> + struct iommu_domain *domain)
> >> +{
> >> +
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:04 PM
>
> +/*
> + * Not all PASID entry destroy requires PRQ drain as it can be handled in
> + * the remove_dev_pasid path. Caller should be clear about it and set the
> + * @flags properly.
> + */
/*
* Caller can request to drain PRQ in
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:04 PM
>
> To support domain replacement for pasid, the underlying iommu driver
> needs
> to know the old domain hence be able to clean up the existing attachment.
> It would be much convenient for iommu layer to pass down the old domain.
>
> From: Jason Gunthorpe
> Sent: Thursday, August 22, 2024 10:46 PM
>
> These three implementations of map_pages() all succeed if a mapping is
> requested with no read or write. Since they return back to __iommu_map()
> leaving the mapped output as 0 it triggers an infinite loop. Therefore
> nothi
> From: Jason Gunthorpe
> Sent: Thursday, August 22, 2024 10:46 PM
>
> This results in passing 0 or just IOMMU_CACHE to iommu_map(). Most of
> the page table formats don't like this:
>
> amdv1 - -EINVAL
> armv7s - returns 0, doesn't update mapped
> arm-lpae - returns 0 doesn't update mappe
> From: Nicolin Chen
> Sent: Friday, August 9, 2024 7:00 AM
>
> On Thu, Aug 08, 2024 at 01:38:44PM +0100, Robin Murphy wrote:
> > On 06/08/2024 9:25 am, Tian, Kevin wrote:
> > > > From: Nicolin Chen
> > > > Sent: Saturday, August 3, 2024
> From: Robin Murphy
> Sent: Thursday, August 8, 2024 8:39 PM
>
> On 06/08/2024 9:25 am, Tian, Kevin wrote:
> >> From: Nicolin Chen
> >> Sent: Saturday, August 3, 2024 8:32 AM
> >>
> >> From: Robin Murphy
> >>
> >> Cur
> From: Nicolin Chen
> Sent: Saturday, August 3, 2024 8:32 AM
>
> From: Robin Murphy
>
> Currently, iommu-dma is the only place outside of IOMMUFD and drivers
> which might need to be aware of the stage 2 domain encapsulated within
> a nested domain. This would be in the legacy-VFIO-style case
> From: Jason Gunthorpe
> Sent: Tuesday, August 6, 2024 7:23 AM
>
> On Mon, Aug 05, 2024 at 02:24:42AM +, Tian, Kevin wrote:
> >
> > According to [3],
> >
> > "
> > With SNP, when pages are marked as guest-owned in the RMP table,
> > t
> From: Jason Gunthorpe
> Sent: Friday, August 2, 2024 7:22 PM
>
> On Fri, Aug 02, 2024 at 08:26:48AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, June 20, 2024 10:34 PM
> > >
> > > On Thu, Jun 20, 2024 at 04:14:23PM
> From: Jason Gunthorpe
> Sent: Thursday, June 20, 2024 10:34 PM
>
> On Thu, Jun 20, 2024 at 04:14:23PM +0200, David Hildenbrand wrote:
>
> > 1) How would the device be able to grab/access "private memory", if not
> >via the user page tables?
>
> The approaches I'm aware of require the secu
> From: Liu, Yi L
> Sent: Friday, June 28, 2024 5:06 PM
>
> @@ -3289,7 +3290,20 @@ static int __iommu_set_group_pasid(struct
> iommu_domain *domain,
>
> if (device == last_gdev)
> break;
> - ops->remove_dev_pasid(device->dev, pasid, domain);
> +
> From: Liu, Yi L
> Sent: Sunday, March 10, 2024 9:06 PM
>
> On 2024/1/16 01:19, Jason Gunthorpe wrote:
> > On Sun, Nov 26, 2023 at 10:34:21PM -0800, Yi Liu wrote:
> >> +int iommu_replace_device_pasid(struct iommu_domain *domain,
> >> + struct device *dev, ioasid_t pasid)
> From: Joao Martins
> Sent: Friday, February 9, 2024 6:36 PM
>
> On 08/02/2024 10:31, Joao Martins wrote:
> > On 08/02/2024 09:14, Yi Liu wrote:
> >> Should set the SSADE (Second Stage Access/Dirty bit Enable) bit of the
> >> pasid entry when attaching a device to a nested domain if its parent
>
> From: Liu, Yi L
> Sent: Thursday, February 8, 2024 4:23 PM
>
> @@ -4760,6 +4790,12 @@ static int intel_iommu_set_dirty_tracking(struct
> iommu_domain *domain,
> if (ret)
> goto err_unwind;
>
> + if (dmar_domain->nested_parent) {
> + ret = parent_domain_set_d
> From: Liu, Yi L
> Sent: Thursday, February 8, 2024 4:23 PM
>
> Add device_set_dirty_tracking() to loop all the devices and set the dirty
> tracking per the @enable parameter.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Thursday, February 8, 2024 4:23 PM
>
> The only usage of input @domain is to get the domain id (DID) to flush
> cache after setting dirty tracking. However, DID can be obtained from
> the pasid entry. So no need to pass in domain. This can make this helper
> cleaner when
> From: Liu, Yi L
> Sent: Thursday, February 8, 2024 4:23 PM
>
> ATS-capable devices cache the result of nested translation. This result
> relies on the mappings in s2 domain (a.k.a. parent). When there are
> modifications in the s2 domain, the related nested translation caches on
> the device sh
> From: Liu, Yi L
> Sent: Thursday, February 8, 2024 4:23 PM
>
> Should call domain_update_iotlb() to update the has_iotlb_device flag
> of the domain after attaching device to nested domain. Without it, this
> flag is not set properly and would result in missing device TLB flush.
>
> Fixes: 983
> From: Liu, Yi L
> Sent: Thursday, February 8, 2024 4:23 PM
>
> +/*
> + * Flush the relevant caches in nested translation if the domain
> + * also serves as a parent
> + */
> +static void parent_domain_flush(struct dmar_domain *domain,
> + unsigned long pfn,
> +
> From: Liu, Yi L
> Sent: Thursday, February 8, 2024 4:23 PM
>
> Add __iommu_flush_iotlb_psi() to do the psi iotlb flush with a DID input
> rather than calculating it within the helper.
>
> This is useful when flushing cache for parent domain which reuses DIDs of
> its nested domains.
>
> Signe
> From: Liu, Yi L
> Sent: Thursday, February 8, 2024 4:23 PM
>
> static void intel_nested_domain_free(struct iommu_domain *domain)
> {
> + struct dmar_domain *dmar_domain = to_dmar_domain(domain);
> + struct dmar_domain *s2_domain = dmar_domain->s2_domain;
> +
> + spin_lock(&s2_doma
> From: Jason Gunthorpe
> Sent: Tuesday, January 16, 2024 8:58 PM
>
> On Tue, Jan 16, 2024 at 01:18:12AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, January 16, 2024 1:25 AM
> > >
> > > On Sun
> From: Jason Gunthorpe
> Sent: Tuesday, January 16, 2024 1:25 AM
>
> On Sun, Nov 26, 2023 at 10:34:23PM -0800, Yi Liu wrote:
> > +/**
> > + * iommufd_device_pasid_detach - Disconnect a {device, pasid} to an
> iommu_domain
> > + * @idev: device to detach
> > + * @pasid: pasid to detach
> > + *
>
> From: Yi Liu
> Sent: Thursday, January 11, 2024 12:10 PM
>
> v11:
> - Drop hw_error field in vtd cache invalidation uapi. devTLB invalidation
>error is a serious security emergency requiring the host kernel to handle.
>No need to expose it to userspace (especially given existing VMs do
> From: Jason Gunthorpe
> Sent: Friday, January 5, 2024 10:45 PM
>
> On Fri, Jan 05, 2024 at 02:52:50AM +, Tian, Kevin wrote:
> > > but in reality the relation could be identified in an easy way due to a
> > > SIOV
> > > restriction which we disc
> From: Tian, Kevin
> Sent: Friday, January 5, 2024 10:16 AM
>
> > From: Jason Gunthorpe
> > Sent: Thursday, January 4, 2024 10:37 PM
> >
> > On Thu, Dec 14, 2023 at 07:26:39PM +0800, Yi Liu wrote:
> > > Per the prior discussion[1], we agreed to move t
> From: Jason Gunthorpe
> Sent: Thursday, January 4, 2024 10:37 PM
>
> On Thu, Dec 14, 2023 at 07:26:39PM +0800, Yi Liu wrote:
> > Per the prior discussion[1], we agreed to move the error reporting into the
> > driver specific part. On Intel side, we want to report two devTLB
> > invalidation err
> From: Liu, Yi L
> Sent: Thursday, December 28, 2023 11:06 PM
>
> This series is based on the first part which was merged [1], this series is to
> add the cache invalidation interface or the userspace to invalidate cache
> after
> modifying the stage-1 page table. This includes both the iommufd
> From: Liu, Yi L
> Sent: Thursday, December 28, 2023 11:06 PM
>
> From: Lu Baolu
>
> This implements the .cache_invalidate_user() callback to support iotlb
> flush for nested domain.
>
> Signed-off-by: Lu Baolu
> Co-developed-by: Yi Liu
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Thursday, December 28, 2023 11:06 PM
>
> From: Lu Baolu
>
> This allows qi_submit_sync() to return back faults to callers.
this might be useful to add a note that the retry logic itself is being
discussed
in a separate thread [1]. Here we keep it intact and just make
> From: Liu, Yi L
> Sent: Thursday, December 28, 2023 12:14 AM
>
>
> +static void nested_flush_pasid_iotlb(struct intel_iommu *iommu,
> + struct dmar_domain *domain, u64 addr,
> + unsigned long npages, bool ih)
> +{
> + u16 di
> From: Tian, Kevin
> Sent: Thursday, December 28, 2023 2:38 PM
>
> > From: Liu, Yi L
> > Sent: Thursday, December 28, 2023 12:14 AM
> > +/**
> > + * struct iommu_hwpt_vtd_s1_invalidat
> From: Liu, Yi L
> Sent: Thursday, December 28, 2023 12:14 AM
> +/**
> + * struct iommu_hwpt_vtd_s1_invalidate - Intel VT-d cache invalidation
> + * (IOMMU_HWPT_INVALIDATE_DATA_VTD_S1)
> + * @addr: The start address of the range to be invalidated. It needs to
> From: Liu, Yi L
> Sent: Thursday, December 28, 2023 12:14 AM
>
> From: Lu Baolu
>
> This makes the pasid based cache invalidation and device TLB invalidation
> to return QI faults to callers. This is needed when usersapce invalidates
> cache after modifying the stage-1 page table used in nest
> From: Liu, Yi L
> Sent: Thursday, December 28, 2023 12:14 AM
>
> @@ -1376,6 +1383,8 @@ int qi_submit_sync(struct intel_iommu *iommu,
> struct qi_desc *desc,
>
> restart:
> rc = 0;
> + if (fault)
> + *fault = 0;
move it to right before the loop of qi_check_fault()
>
>
> From: Liu, Yi L
> Sent: Thursday, December 28, 2023 12:14 AM
>
> + /* Negative test: trigger error */
> + num_inv = 1;
> + inv_reqs[0].flags =
> IOMMU_TEST_INVALIDATE_FLAG_TRIGGER_ERROR;
> + inv_reqs[0].iotlb_id = 0;
> + test_cmd_hwpt_
> From: Liu, Yi L
> Sent: Thursday, December 28, 2023 12:14 AM
>
> In nested translation, the stage-1 page table is user-managed but cached
> by the IOMMU hardware, so an update on present page table entries in the
> stage-1 page table should be followed with a cache invalidation.
>
> Add an IOM
t; Sent: Tuesday, December 26, 2023 4:44 PM
> >>> Subject: Re: [PATCH v7 7/9] iommu/vt-d: Allow qi_submit_sync() to
> return
> >>> the QI faults
> >>>
> >>> On 2023/12/26 14:15, Yi Liu wrote:
> >>>>
> >>>> On 2023/12
> From: Liu, Yi L
> Sent: Tuesday, December 26, 2023 4:44 PM
>
> On 2023/12/26 14:15, Yi Liu wrote:
> >
> >
> > On 2023/12/26 12:13, Tian, Kevin wrote:
> >>> From: Liu, Yi L
> >>> Sent: Tuesday, December 26, 2023 12:03 PM
> >>>
&
> From: Liu, Yi L
> Sent: Tuesday, December 26, 2023 12:52 PM
> >> +
> >> + if (!IS_ALIGNED(inv_entry.addr, VTD_PAGE_SIZE) ||
> >> + ((inv_entry.npages == U64_MAX) && inv_entry.addr)) {
> >> + ret = -EINVAL;
> >> + break;
> >> + }
>
> From: Liu, Yi L
> Sent: Tuesday, December 26, 2023 12:03 PM
>
> On 2023/12/22 12:23, Tian, Kevin wrote:
> >> From: Liu, Yi L
> >> Sent: Thursday, December 21, 2023 11:40 PM
> >>
> >> + fault &= DMA_FSTS_IQE | DMA_FSTS_ITE | DMA_FST
> From: Liu, Yi L
> Sent: Friday, December 22, 2023 3:02 PM
>
>
> > On Dec 22, 2023, at 14:47, Tian, Kevin wrote:
> >
> >
> >>
> >> From: Yang, Weijiang
> >> Sent: Friday, December 22, 2023 11:56 AM
>
> From: Liu, Yi L
> Sent: Thursday, December 21, 2023 11:40 PM
>
> +
> +static void intel_nested_flush_cache(struct dmar_domain *domain, u64
> addr,
> + unsigned long npages, u32 *error)
> +{
> + struct iommu_domain_info *info;
> + unsigned long i;
> +
> From: Yang, Weijiang
> Sent: Friday, December 22, 2023 11:56 AM
> > +
> > + xa_for_each(&domain->iommu_array, i, info) {
> > + nested_flush_pasid_iotlb(info->iommu, domain, addr,
> npages, 0);
> > +
> > + if (domain->has_iotlb_device)
> > + continue;
>
>
> From: Liu, Yi L
> Sent: Thursday, December 21, 2023 11:40 PM
>
> From: Lu Baolu
>
> This makes the pasid based cache invalidation to return QI faults to callers.
it's not just for pasid cache invalidation, e.g. there is also change on
qi_flush_dev_iotlb().
> This is needed when usersapce wa
> From: Liu, Yi L
> Sent: Thursday, December 21, 2023 11:40 PM
>
> + fault &= DMA_FSTS_IQE | DMA_FSTS_ITE | DMA_FSTS_ICE;
> + if (fault) {
> + if (fsts)
> + *fsts |= fault;
do we expect the fault to be accumulated? otherwise it's clearer to
just do direct a
> From: Liu, Yi L
> Sent: Thursday, December 21, 2023 11:40 PM
>
> From: Nicolin Chen
>
> Add test cases for the IOMMU_HWPT_INVALIDATE ioctl and verify it by using
> the new IOMMU_TEST_OP_MD_CHECK_IOTLB.
>
> Signed-off-by: Nicolin Chen
> Co-developed-by: Yi Liu
> Signed-off-by: Yi Liu
over
> From: Liu, Yi L
> Sent: Thursday, December 21, 2023 11:40 PM
>
> From: Nicolin Chen
>
> Allow to test whether IOTLB has been invalidated or not.
>
> Signed-off-by: Nicolin Chen
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Thursday, December 21, 2023 11:40 PM
> +
> +
> + if ((inv.flags & IOMMU_TEST_INVALIDATE_FLAG_ALL) &&
> + (inv.flags &
> IOMMU_TEST_INVALIDATE_FLAG_TRIGGER_ERROR)) {
> + rc = -EINVAL;
> + break;
> +
> From: Liu, Yi L
> Sent: Thursday, December 21, 2023 11:40 PM
>
> From: Nicolin Chen
>
> Wrap up the data pointer/num sanity and __iommu_copy_struct_from_user
> call for iommu drivers to copy driver specific data at a specific location
> in the struct iommu_user_data_array, and
> iommu_respond
> From: Liu, Yi L
> Sent: Thursday, December 21, 2023 11:40 PM
> +
> +int iommufd_hwpt_invalidate(struct iommufd_ucmd *ucmd)
> +{
> + struct iommu_hwpt_invalidate *cmd = ucmd->cmd;
> + struct iommu_user_data_array data_array = {
> + .type = cmd->req_type,
> + .uptr
> From: Liu, Yi L
> Sent: Thursday, December 21, 2023 11:40 PM
>
> From: Lu Baolu
>
> The updates of the PTEs in the nested page table will be propagated to the
> hardware caches on both IOMMU (IOTLB) and devices (DevTLB/ATC).
this is incorrect. the scope of this cmd is driver specific.
>
>
> From: Nicolin Chen
> Sent: Sunday, December 17, 2023 2:49 AM
>
> On Fri, Dec 15, 2023 at 12:01:19PM +0800, Yi Liu wrote:
> > On 2023/12/15 11:32, Nicolin Chen wrote:
> > > On Fri, Dec 15, 2023 at 03:04:44AM +, Tian, Kevin wrote:
> > > > >
> From: Nicolin Chen
> Sent: Friday, December 15, 2023 10:28 AM
>
> On Fri, Dec 15, 2023 at 01:50:07AM +, Tian, Kevin wrote:
> > > From: Liu, Yi L
> > > Sent: Thursday, December 14, 2023 7:27 PM
> > >
> > > On 2023/11/17 21:18, Yi Liu wrote:&
> From: Liu, Yi L
> Sent: Thursday, December 14, 2023 7:27 PM
>
> On 2023/11/17 21:18, Yi Liu wrote:> This adds the data structure for
> flushing iotlb for the nested domain
>
> +struct iommu_hwpt_vtd_s1_invalidate {
> + __aligned_u64 addr;
> + __aligned_u64 npages;
> + __u32 flags;
> From: Baolu Lu
> Sent: Wednesday, December 13, 2023 10:05 AM
> >
> >> 2. This is not intended to work only with idxd and uacce. right?
> > It should work everywhere, I suspect Intel Team didn't hit this
> > because they are testing IDXD SIOV?
>
> Yes.
>
> > Can you guys also test it as a PF
>
> From: Jason Gunthorpe
> Sent: Tuesday, December 12, 2023 11:35 PM
>
> On Mon, Dec 11, 2023 at 11:49:49AM -0700, Alex Williamson wrote:
> > On Mon, 11 Dec 2023 14:10:28 -0400
> > Jason Gunthorpe wrote:
> >
> > > On Mon, Dec 11, 2023 at 11:03:45AM -0700, Alex Williamson wrote:
> > > > On Sun, 26
> From: Jason Gunthorpe
> Sent: Tuesday, December 12, 2023 11:32 PM
>
> On Tue, Dec 12, 2023 at 02:20:01AM +, Tian, Kevin wrote:
> > > From: Liu, Yi L
> > > Sent: Monday, December 11, 2023 4:08 PM
> > >
> > > On 2023/12/7 16:47, Tian, Kevi
> From: Liu, Yi L
> Sent: Monday, December 11, 2023 4:08 PM
>
> On 2023/12/7 16:47, Tian, Kevin wrote:
> >> From: Liu, Yi L
> >> Sent: Monday, November 27, 2023 2:39 PM
> >>
> >> +static int vfio_pci_core_featu
> From: Alex Williamson
> Sent: Tuesday, December 12, 2023 2:04 AM
>
> On Sun, 26 Nov 2023 22:39:09 -0800
> Yi Liu wrote:
>
> > This reports the PASID capability data to userspace via
> VFIO_DEVICE_FEATURE,
> > hence userspace could probe PASID capability by it. This is a bit different
> > with
> From: Jason Gunthorpe
> Sent: Saturday, December 9, 2023 9:47 AM
>
> What is in a Nested domain:
> Intel: A single IO page table refereed to by a PASID entry
> Each vDomain-ID,PASID allocates a unique nesting domain
> AMD: A GCR3 table pointer
> Nesting domains are created for e
> From: Liu, Yi L
> Sent: Thursday, December 7, 2023 2:59 PM
>
> On 2023/11/17 21:07, Yi Liu wrote:
> > @@ -613,4 +614,38 @@ struct iommu_hwpt_get_dirty_bitmap {
> > #define IOMMU_HWPT_GET_DIRTY_BITMAP _IO(IOMMUFD_TYPE, \
> >
> IOMMUFD_CMD_HWPT_GET_DIRTY_BITMAP)
> >
> > +/**
> > + * struc
> From: Liu, Yi L
> Sent: Monday, November 27, 2023 2:39 PM
>
> +static int vfio_pci_core_feature_pasid(struct vfio_device *device, u32 flags,
> +struct vfio_device_feature_pasid __user
> *arg,
> +size_t argsz)
> +{
> + s
> From: Liu, Yi L
> Sent: Friday, December 1, 2023 3:05 PM
>
> On 2023/12/1 13:19, Tian, Kevin wrote:
> >> From: Nicolin Chen
> >> Sent: Friday, December 1, 2023 12:50 PM
> >>
> >> On Fri, Dec 01, 2023 at 11:51:26AM +0800, Yi Liu wrote:
> From: Nicolin Chen
> Sent: Friday, December 1, 2023 12:50 PM
>
> On Fri, Dec 01, 2023 at 11:51:26AM +0800, Yi Liu wrote:
> > On 2023/11/29 08:57, Jason Gunthorpe wrote:
> > > On Tue, Nov 28, 2023 at 04:51:21PM -0800, Nicolin Chen wrote:
> > > > > > I also thought about making this out_driver_er
> From: Nicolin Chen
> Sent: Tuesday, November 28, 2023 3:53 AM
>
> On Fri, Nov 24, 2023 at 02:36:29AM +, Tian, Kevin wrote:
>
> > > > > > > >> + * @out_driver_error_code: Report a driver speicifc error code
> > > upon
> > > > &
> From: Jason Gunthorpe
> Sent: Wednesday, November 22, 2023 9:26 PM
>
> On Wed, Nov 22, 2023 at 04:58:24AM +, Tian, Kevin wrote:
> > then we just define hwpt 'cache' invalidation in vtd always refers to
> > both iotlb and devtlb. Then viommu just needs
> From: Nicolin Chen
> Sent: Tuesday, November 21, 2023 1:24 PM
>
> On Tue, Nov 21, 2023 at 02:50:05AM +, Tian, Kevin wrote:
> > > From: Nicolin Chen
> > > Sent: Tuesday, November 21, 2023 1:37 AM
> > >
> > > On Mon, Nov 20, 2023 at 08:34:58
> From: Jason Gunthorpe
> Sent: Tuesday, November 21, 2023 8:17 PM
>
> On Tue, Nov 21, 2023 at 02:54:15AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, November 21, 2023 7:05 AM
> > >
> > > On Mon, Nov 20, 2023 at 08:
> From: Jason Gunthorpe
> Sent: Tuesday, November 21, 2023 7:05 AM
>
> On Mon, Nov 20, 2023 at 08:26:31AM +, Tian, Kevin wrote:
> > > From: Liu, Yi L
> > > Sent: Friday, November 17, 2023 9:18 PM
> > >
> > > This adds the data st
> From: Nicolin Chen
> Sent: Tuesday, November 21, 2023 1:37 AM
>
> On Mon, Nov 20, 2023 at 08:34:58AM +, Tian, Kevin wrote:
> > > From: Liu, Yi L
> > > Sent: Monday, November 20, 2023 4:30 PM
> > >
> > > On 2023/11/20 16:09, Tian, Kevi
> From: Nicolin Chen
> Sent: Tuesday, November 21, 2023 1:25 AM
>
> On Mon, Nov 20, 2023 at 08:17:47AM +, Tian, Kevin wrote:
> > > From: Liu, Yi L
> > > Sent: Friday, November 17, 2023 9:07 PM
> > >
> > > +/**
> > > + * __iommu
> From: Liu, Yi L
> Sent: Monday, November 20, 2023 4:30 PM
>
> On 2023/11/20 16:09, Tian, Kevin wrote:
> >> From: Liu, Yi L
> >> Sent: Friday, November 17, 2023 9:07 PM
> >> + * @req_len: Length (in bytes) of a request entry in the request array
>
> From: Liu, Yi L
> Sent: Friday, November 17, 2023 9:18 PM
> +
> + if (inv_info.__reserved || (inv_info.flags &
> ~IOMMU_VTD_INV_FLAGS_LEAF) ||
> + !IS_ALIGNED(inv_info.addr, VTD_PAGE_SIZE)) {
> + ret = -EINVAL;
> + break;
> +
> From: Liu, Yi L
> Sent: Friday, November 17, 2023 9:18 PM
>
> This adds the data structure for flushing iotlb for the nested domain
> allocated with IOMMU_HWPT_DATA_VTD_S1 type.
>
> This only supports invalidating IOTLB, but no for device-TLB as device-TLB
> invalidation will be covered automa
> From: Liu, Yi L
> Sent: Friday, November 17, 2023 9:07 PM
>
> +/**
> + * __iommu_copy_struct_from_user_array - Copy iommu driver specific
__iommu_copy_entry_from_user_array?
> From: Liu, Yi L
> Sent: Friday, November 17, 2023 9:07 PM
> +
> + hwpt = iommufd_hw_pagetable_get_nested(ucmd, cmd->hwpt_id);
> + if (IS_ERR(hwpt))
> + return PTR_ERR(hwpt);
> +
> + rc = hwpt->domain->ops->cache_invalidate_user(hwpt->domain,
> &data_array,
> +
> From: Yi Liu
> Sent: Friday, November 17, 2023 9:07 PM
>
> +/**
> + * struct iommu_user_data_array - iommu driver specific user space data
> array
> + * @type: The data type of all the entries in the user buffer array
> + * @uptr: Pointer to the user buffer array for copy_from_user()
remove "f
> From: Jason Gunthorpe
> Sent: Wednesday, November 8, 2023 1:54 AM
>
> On Tue, Nov 07, 2023 at 08:35:10AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, November 2, 2023 8:48 PM
> > >
> > > On Thu, Oct 26, 2023 at 10
> From: Liu, Yi L
> Sent: Wednesday, November 8, 2023 3:45 PM
>
> On 2023/10/10 16:19, Tian, Kevin wrote:
> >> From: Liu, Yi L
> >> Sent: Monday, October 9, 2023 4:51 PM
> >>
> >> +struct iommufd_device *iommufd_d
> From: Jason Gunthorpe
> Sent: Thursday, November 2, 2023 8:48 PM
>
> On Thu, Oct 26, 2023 at 10:49:24AM +0800, Lu Baolu wrote:
> > Hi folks,
> >
> > This series implements the functionality of delivering IO page faults to
> > user space through the IOMMUFD framework for nested translation.
> Nes
> From: Liu, Yi L
> Sent: Thursday, October 26, 2023 12:42 PM
>
> From: Lu Baolu
>
> This adds the support for IOMMU_HWPT_DATA_VTD_S1 type. And
> 'nested_parent'
> is added to mark the nested parent domain to sanitize the input parent
> domain.
>
> Signed-off-by: Lu Baolu
> Signed-off-by: Yi
> From: Liu, Yi L
> Sent: Tuesday, October 24, 2023 11:14 PM
>
> +/**
> + * enum iommu_hw_info_vtd_flags - Flags for VT-d hw_info
> + * @IOMMU_HW_INFO_VTD_ERRATA_772415_SPR17: If set, disallow
> nesting on domains
> + * with read-only mapping.
with how it's imple
> From: Liu, Yi L
> Sent: Tuesday, October 24, 2023 11:00 PM
>
> This adds the scalable mode check before allocating the nested parent
> domain
> as checking nested capability is not enough. User may turn off scalable mode
> which also means no nested support even if the hardware supports it.
>
> From: Jason Gunthorpe
> Sent: Wednesday, October 25, 2023 7:03 AM
>
> @@ -4849,6 +4855,7 @@ static void *intel_iommu_hw_info(struct device
> *dev, u32 *length, u32 *type)
> if (!vtd)
> return ERR_PTR(-ENOMEM);
>
> + vtd->flags = IOMMU_HW_INFO_VTD_ERRATA_772415_SPR17;
th
1 - 100 of 152 matches
Mail list logo
