On Mon, Jul 28, 2025 at 11:23:42AM +, Ankit Soni wrote:
> > +static __always_inline struct pt_range _pt_top_range(struct pt_common
> > *common,
> > +uintptr_t top_of_table)
> > +{
> > + struct pt_range range = {
> > + .common = common
On Mon, Jul 14, 2025 at 08:08:21AM +0200, Arnd Bergmann wrote:
> The mtree_alloc_range() interface explicitly operates on 'unsigned long'
> address values, so I don't see an immediate workaround for this that would
> make it work on these machines. On the other hand,
I fixed this already, PHYS_
On Thu, Jul 10, 2025 at 04:43:14PM +, Pranjal Shrivastava wrote:
> On Thu, Jul 10, 2025 at 12:32:02PM -0300, Jason Gunthorpe wrote:
> Alright, this was on the `for-next` branch when the head was at:
> 3e2a9811f6a9cefd310cc33cab73d5435b4a4caa
> iommufd: Apply the new iommufd_objec
On Thu, Jul 10, 2025 at 11:09:26AM +, Pranjal Shrivastava wrote:
> On Wed, Jul 09, 2025 at 10:59:14PM -0700, Nicolin Chen wrote:
> > Test both IOMMU_HW_INFO_TYPE_DEFAULT and IOMMU_HW_INFO_TYPE_SELFTEST, and
> > add a negative test for an unsupported type.
> >
> > Also drop the unused mask in t
On Wed, Jul 09, 2025 at 08:56:19AM +, Ankit Soni wrote:
>
> Hi Jason,
> I noticed a few minor nits that might be worth addressing in a future
> revision.
Got them all thanks
Jason
On Fri, Jul 04, 2025 at 06:13:16PM -0700, Nicolin Chen wrote:
> Nicolin Chen (29):
> iommufd: Report unmapped bytes in the error path of
> iopt_unmap_iova_range
> iommufd: Correct virt_id kdoc at struct iommu_vdevice_alloc
> iommufd/viommu: Explicitly define vdev->virt_id
> iommu: Use e
On Fri, Jul 04, 2025 at 06:13:30PM -0700, Nicolin Chen wrote:
> +static struct iommufd_access *
> +iommufd_hw_queue_alloc_phys(struct iommu_hw_queue_alloc *cmd,
> + struct iommufd_viommu *viommu, phys_addr_t *base_pa)
> +{
> + struct iommufd_access *access;
> + struc
s changed, 9 insertions(+), 6 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Tue, Jul 08, 2025 at 06:36:35AM +, Ankit Soni wrote:
> > Tested-by: Alejandro Jimenez
> > Signed-off-by: Jason Gunthorpe
>
> Tested patch series with multiple command line configurations for amd
> iommu on zen5 machine with 12 NVMe devices.
>
> Suggested-
On Fri, Jul 04, 2025 at 10:26:02AM -0300, Jason Gunthorpe wrote:
> /* DIV_ROUND_UP(offset + cmd->length, PAGE_SIZE) */
> if (check_add_overflow(offset, cmd->length, &length))
>return -ERANGE;
> if (check_add_overflow(length, PAGE_SIZE-1, &length))
>return -ER
> SIZE_MAX)
return -ERANGE;
max_npages = length / PAGE_SIZE;
And then max_npages and i should be size_t.
Otherwise it looks OK
Reviewed-by: Jason Gunthorpe
Jason
ufd/device.c | 59 +++++----
> 2 files changed, 73 insertions(+), 9 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
| 6 +++---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 3 ++-
> drivers/iommu/intel/iommu.c | 3 ++-
> drivers/iommu/iommufd/selftest.c| 3 ++-
> 4 files changed, 9 insertions(+), 6 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
rivers/iommu/iommufd/iommufd_private.h | 7 ++-
> drivers/iommu/iommufd/driver.c | 2 +-
> drivers/iommu/iommufd/viommu.c | 4 ++--
> 3 files changed, 9 insertions(+), 4 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
; access")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Nicolin Chen
> ---
> drivers/iommu/iommufd/io_pagetable.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Thu, Jul 03, 2025 at 06:48:42PM +, Pranjal Shrivastava wrote:
> Ahh, thanks for this, that saved a lot of my time! And yes, I see some
> functions in eventq.c calling the iopf_group_response which settles the
> CMD_RESUME. So.. I assume these resume commands would be trapped and
> *actually
On Thu, Jul 03, 2025 at 02:46:03PM +, Pranjal Shrivastava wrote:
> Right.. I was however hoping we'd also trap commands like CMD_PRI_RESP
> and CMD_RESUME...I'm not sure if they should be accelerated via CMDQV..
> I guess I'll need to look and understand a little more if they are..
Right now
On Wed, Jul 02, 2025 at 01:38:33AM +, Pranjal Shrivastava wrote:
> On Tue, Jul 01, 2025 at 05:46:06PM -0700, Nicolin Chen wrote:
> > On Wed, Jul 02, 2025 at 12:14:28AM +, Pranjal Shrivastava wrote:
> > > Thus, coming back to the two initial points:
> > >
> > > 1) Issuing "non-invalidation"
On Thu, Jun 19, 2025 at 11:47:24AM +, Pranjal Shrivastava wrote:
> I'm not sure if I get this right.. if the user (while porting a VMM or
> something) mistakenly passes *type == IOMMU_HW_INFO_TYPE_INTEL_VTD here,
> they'll get impl-specific info?
It should call the impl hw_info which should fa
On Thu, Jun 19, 2025 at 10:26:28AM +, Pranjal Shrivastava wrote:
> > +struct iommufd_vdevice {
> > + struct iommufd_object obj;
> > + struct iommufd_viommu *viommu;
> > + struct device *dev;
> > + u64 id; /* per-vIOMMU virtual ID */
>
> Nit: Why not call this viommu_id?
And lets have
On Tue, Jun 17, 2025 at 08:59:34AM +0700, Bagas Sanjaya wrote:
> On Mon, Jun 16, 2025 at 03:06:05PM -0300, Jason Gunthorpe wrote:
> > +The generic tests are intended to prove out the format functions and give
> > +clearer failures to speed finding the problems. Once those pass then
On Mon, Jun 16, 2025 at 07:37:26PM -0700, Nicolin Chen wrote:
> On Mon, Jun 16, 2025 at 11:13:19AM -0300, Jason Gunthorpe wrote:
> > On Sat, Jun 14, 2025 at 12:14:38AM -0700, Nicolin Chen wrote:
> >
> > > +/* Entry for iommufd_ctx::mt_mmap */
> > > +str
On Tue, Jun 17, 2025 at 12:23:20PM +0800, Baolu Lu wrote:
> On 6/17/25 10:25, Nicolin Chen wrote:
> > > > struct iommufd_eventq {
> > > > struct iommufd_object obj;
> > > > struct iommufd_ctx *ictx;
> > > > diff --git a/drivers/iommu/iommufd/device.c
> > > > b/drivers/iommu/iommu
ases. This version makes it explicit with a
memset64() call.
Tested-by: Alejandro Jimenez
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/Makefile | 1 +
drivers/iommu/generic_pt/Kconfig | 13 +
drivers/iommu/generic_pt/fmt/Makefile | 11 +
drivers/iommu/gene
None of this is used anymore, delete it.
Tested-by: Alejandro Jimenez
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/amd/Makefile | 2 +-
drivers/iommu/amd/amd_iommu_types.h | 97 -
drivers/iommu/amd/io_pgtable.c | 559
drivers/iommu/amd
map_range() and can do arbitrary ranges, internally handling all the
validation and supporting any arrangment of page sizes. A future series
can optimize iommu_map() to take advantage of this.
Tested-by: Alejandro Jimenez
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/generic_pt/iommu_pt.h | 480
their different roles with no change to any of the existing
iommu core code.
Implement the basic starting point: pt_iommu_init(), get_info() and
deinit().
Tested-by: Alejandro Jimenez
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/generic_pt/Kconfig | 13 +
drivers/iommu
Add some general description and pull in the kdoc comments from the source
file to index most of the useful functions.
Tested-by: Alejandro Jimenez
Signed-off-by: Jason Gunthorpe
---
Documentation/driver-api/generic_pt.rst | 140
Documentation/driver-api/index.rst
ll if a contiguous entry
is dirty, and a function to clear a contiguous entry back to clean.
Tested-by: Alejandro Jimenez
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/generic_pt/iommu_pt.h | 103
include/linux/generic_pt/iommu.h| 6 ++
2 files changed
iommu_pt_...@nvidia.com/
Alejandro Jimenez (1):
iommu/amd: Use the generic iommu page table
Jason Gunthorpe (14):
genpt: Generic Page Table base API
genpt: Add Documentation/ files
iommupt: Add the basic structure of the iommu implementation
iommupt: Add the AMD IOMMU v1 page table format
iova_to_phys is a performance path for the DMA API and iommufd, implement
it using an unrolled get_user_pages() like function waterfall scheme.
The implementation itself is fairly trivial.
Tested-by: Alejandro Jimenez
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/generic_pt/iommu_pt.h
et_write_clean(), pt_entry_make_write_dirty(), and
pt_entry_write_is_dirty() work
Tested-by: Alejandro Jimenez
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/generic_pt/.kunitconfig | 12 +
drivers/iommu/generic_pt/Kconfig | 12 +
drivers/iommu/generic_pt/fmt/Makefile | 12 +
ommu_unmap() to take advantage of this.
Freed page table memory is batched up in the gather and will be freed in
the driver's iotlb_sync() callback after the IOTLB flush completes.
Tested-by: Alejandro Jimenez
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/generic
functions.
Tested-by: Alejandro Jimenez
Signed-off-by: Jason Gunthorpe
---
.clang-format | 1 +
drivers/iommu/Kconfig | 2 +
drivers/iommu/generic_pt/Kconfig | 22 +
drivers/iommu/generic_pt/pt_common.h | 354
dri
-off-by: Alejandro Jimenez
Tested-by: Alejandro Jimenez
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/amd/Kconfig | 5 +-
drivers/iommu/amd/amd_iommu.h | 1 -
drivers/iommu/amd/amd_iommu_types.h | 12 +-
drivers/iommu/amd/io_pgtable.c | 1 -
drivers/iommu/a
s when
hitting collions doing nothing, unmap/map with random intersections and
full unmap of random sizes. Also checked iommu_iova_to_phys() with random
sizes
- Check for memory leaks by monitoring NR_SECONDARY_PAGETABLE
Tested-by: Alejandro Jimenez
Signed-off-by: Jason Gunthorpe
---
otherwise the logic the test uses
fails. They cannot be broken up or combined.
Aside from aligning the selftest with a real page table implementation,
this helps test the iommupt code itself.
Tested-by: Alejandro Jimenez
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/generic_pt/iommu_pt.h
: Jason Gunthorpe
---
drivers/iommu/generic_pt/fmt/Makefile | 1 +
drivers/iommu/generic_pt/fmt/amdv1.h | 18 --
drivers/iommu/generic_pt/fmt/iommu_mock.c | 10 ++
include/linux/generic_pt/iommu.h | 6 ++
4 files changed, 33 insertions(+), 2 deletions
iommu_pgsize() before invoking the domain op. This is unncessary with this
implementation. Future work optimizes this and gets to 2%, 4%, 3%.
Tested-by: Alejandro Jimenez
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/generic_pt/.kunitconfig | 1 +
drivers/iommu/generic_pt/Kconfig
if (vintf->hyp_own)
> + kfree(vintf);
else ?
Otherwise looks OK to me
Reviewed-by: Jason Gunthorpe
Jason
Signed-off-by: Nicolin Chen
> ---
> .../iommu/arm/arm-smmu-v3/tegra241-cmdqv.c| 37 +++++--
> 1 file changed, 33 insertions(+), 4 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Sat, Jun 14, 2025 at 12:14:45AM -0700, Nicolin Chen wrote:
> This will be used by Tegra241 CMDQV implementation to report a non-default
> HW info data.
>
> Reviewed-by: Jason Gunthorpe
> Signed-off-by: Nicolin Chen
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
rm-smmu-v3/arm-smmu-v3.h | 5 +
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 8
> 2 files changed, 13 insertions(+)
Reviewed-by: Jason Gunthorpe
Jason
include/uapi/linux/iommufd.h | 20 +++-
> drivers/iommu/iommufd/device.c | 9 ++---
> 2 files changed, 25 insertions(+), 4 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
this is already in PAGE_SIZE units.
> + /* Physical range for io_remap_pfn_range() */
> + unsigned long mmio_pfn;
physaddr_t and maybe don't use pfn?
> + unsigned long num_pfns;
size_t
Rest looks OK
Reviewed-by: Jason Gunthorpe
Jason
ude/linux/iommufd.h| 44 ++
> drivers/iommu/iommufd/driver.c | 28 ++
> 2 files changed, 72 insertions(+)
Reviewed-by: Jason Gunthorpe
Jason
On Sat, Jun 14, 2025 at 12:14:35AM -0700, Nicolin Chen wrote:
> + /*
> + * FIXME allocation may fail when sizeof(*pages) * max_npages is
> + * larger than PAGE_SIZE. This might need a new API returning a
> + * bio_vec or something more efficient.
> + */
> + pages = kcall
On Sat, Jun 14, 2025 at 12:14:34AM -0700, Nicolin Chen wrote:
> +struct iommufd_hw_queue {
> + struct iommufd_object obj;
> + struct iommufd_ctx *ictx;
Try to avoid this if we don't need it
Reviewed-by: Jason Gunthorpe
Jason
On Sat, Jun 14, 2025 at 12:14:32AM -0700, Nicolin Chen wrote:
> Now, access->ops can be NULL, to support an internal use case for the new
> HW queue object. Since an access object in this case will be allocated by
> an inernal iommufd object, the refcount on the ictx should be skipped, so
> as not
nal access should be able to use this
mechanism.
Otherwise:
Reviewed-by: Jason Gunthorpe
Jason
On Thu, Jun 05, 2025 at 02:03:58PM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Mon, 5 May 2025 11:18:42 -0300
> Jason Gunthorpe wrote:
>
> > +config IOMMU_PT_X86_64
> > + tristate "IOMMU page table for x86 64 bit, 4/5 levels"
> > + d
On Thu, Jun 05, 2025 at 10:04:35AM -0700, Nicolin Chen wrote:
> On Thu, Jun 05, 2025 at 12:16:48PM -0300, Jason Gunthorpe wrote:
> > On Wed, Jun 04, 2025 at 09:11:07PM -0700, Nicolin Chen wrote:
> >
> > > I found the entire ictx would be locked by iommufd_access_create()
On Mon, May 05, 2025 at 11:18:37AM -0300, Jason Gunthorpe wrote:
> +/*
> + * Check that the items in a contiguous block are all empty. This will
> + * recursively check any tables in the block to validate they are empty and
> + * accumulate them on the free list. Makes no change on
On Wed, Jun 04, 2025 at 09:11:07PM -0700, Nicolin Chen wrote:
> I found the entire ictx would be locked by iommufd_access_create(),
> then the release fop couldn't even get invoked to destroy objects.
Yes, that makes sense..
It looks to me like you can safely leave ictx as NULL instead of
adding
On Mon, Jun 02, 2025 at 10:41:05PM -0700, Nicolin Chen wrote:
> I found that the size_viommu or size_hw_queue might not work using
> a static macro as that RDMA one does:
>
> - The size in vIOMMU case is type dependent. E.g. smmuv3 driver
>uses one iommu_ops to support two types: vSMMU and v
| 3 +++
> drivers/iommu/iommufd/selftest.c| 4
> 6 files changed, 22 insertions(+), 3 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
f-by: Nicolin Chen
> ---
> include/uapi/linux/iommufd.h | 15 +
> .../iommu/arm/arm-smmu-v3/tegra241-cmdqv.c| 22 +++
> 2 files changed, 37 insertions(+)
Reviewed-by: Jason Gunthorpe
Jason
On Tue, May 27, 2025 at 11:41:19AM -0700, Nicolin Chen wrote:
> On Mon, May 26, 2025 at 10:30:46AM -0300, Jason Gunthorpe wrote:
> > On Fri, May 16, 2025 at 01:56:26PM -0700, Nicolin Chen wrote:
> >
> > > > You don't need to move this unless you are using inl
On Fri, May 30, 2025 at 11:23:02AM -0700, Nicolin Chen wrote:
> On Fri, May 30, 2025 at 02:40:37PM -0300, Jason Gunthorpe wrote:
> > On Fri, May 30, 2025 at 10:38:24AM -0700, Nicolin Chen wrote:
> > > On Fri, May 30, 2025 at 01:14:55PM -0300, Jason Gunthorpe wrote:
> > >
On Fri, May 30, 2025 at 10:38:24AM -0700, Nicolin Chen wrote:
> On Fri, May 30, 2025 at 01:14:55PM -0300, Jason Gunthorpe wrote:
> > On Sat, May 17, 2025 at 08:21:31PM -0700, Nicolin Chen wrote:
> > > + offset =
> > > + cmd->nesting_parent_iova - PAGE_
On Fri, May 30, 2025 at 09:59:36AM -0700, Nicolin Chen wrote:
> > > +/* The vm_pgoff must be pre-allocated from mt_mmap, and given to user
> > > space */
> > > +static int iommufd_fops_mmap(struct file *filp, struct vm_area_struct
> > > *vma)
> > > +{
> > > + struct iommufd_ctx *ictx = filp->priv
On Sat, May 17, 2025 at 08:21:45PM -0700, Nicolin Chen wrote:
> +static inline phys_addr_t
> +arm_smmu_domain_ipa_to_pa(struct arm_smmu_domain *smmu_domain, u64 ipa)
> +{
> + if (WARN_ON_ONCE(smmu_domain->stage != ARM_SMMU_DOMAIN_S2))
> + return 0;
> + return iommu_iova_to_phys(
On Sat, May 17, 2025 at 08:21:38PM -0700, Nicolin Chen wrote:
> @@ -666,7 +678,7 @@ struct iommu_hw_info {
> __u32 dev_id;
> __u32 data_len;
> __aligned_u64 data_uptr;
> - __u32 out_data_type;
> + __u32 data_type;
It would be better to avoid changing this name, maybe stic
/arm-smmu-v3/arm-smmu-v3-iommufd.c | 8 ++--
> 2 files changed, 7 insertions(+), 2 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Sat, May 17, 2025 at 08:21:34PM -0700, Nicolin Chen wrote:
> +/*
> + * Helpers for IOMMU driver to alloc/destroy an mmapable area for a
> structure.
> + *
> + * To support an mmappable MMIO region, kernel driver must first register it
> to
> + * iommufd core to allocate an @out_offset, in the
On Sat, May 17, 2025 at 08:21:31PM -0700, Nicolin Chen wrote:
> +int iommufd_hw_queue_alloc_ioctl(struct iommufd_ucmd *ucmd)
> +{
> + struct iommu_hw_queue_alloc *cmd = ucmd->cmd;
> + struct iommufd_hw_queue *hw_queue;
> + struct iommufd_viommu *viommu;
> + struct page **pages;
> +
On Sat, May 17, 2025 at 08:21:30PM -0700, Nicolin Chen wrote:
> struct iommufd_viommu_ops {
> + u32 flags;
> void (*destroy)(struct iommufd_viommu *viommu);
> struct iommu_domain *(*alloc_domain_nested)(
> struct iommufd_viommu *viommu, u32 flags,
> @@ -171,6 +200,10
gt; for a pair of iopt helpers that can be shared with the HW QUEUE allocator.
>
> Rename check_area_prot() to align with the existing iopt_area helpers, and
> inline it to the header since iommufd_access_rw() still uses it.
>
> Reviewed-by: Pranjal Shrivastava
> Reviewed-by: Kevin Ti
On Sat, May 17, 2025 at 08:21:26PM -0700, Nicolin Chen wrote:
> Do not allow to unmap an iopt_area that is owned by an object, giving this
> owner a choice to lock the mapping in the iopt.
>
> It will be used by vIOMMU's HW QUEUE structure that must prevent the queue
> memory from being unmapped i
n to all existing
> viommu_alloc op accordingly.
>
> Note that __iommufd_object_alloc_ucmd() builds in some static tests that
> cover both static_asserts in the iommufd_viommu_alloc(). Thus drop them.
>
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Nicolin Chen
> ---
>
abort itself.
>
> Similar to iommufd_object_alloc() and __iommufd_object_alloc(), add a pair
> of helpers: __iommufd_object_alloc_ucmd() and iommufd_object_alloc_ucmd().
>
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Nicolin Chen
> ---
> drivers/iommu/iommu
> 10 files changed, 27 insertions(+), 38 deletions(-)
I have mixed feelings, I know people don't like churn, but it doesn't
seem so bad..
Reviewed-by: Jason Gunthorpe
Jason
On Fri, May 16, 2025 at 01:56:26PM -0700, Nicolin Chen wrote:
> > You don't need to move this unless you are using inlines. Just use a
> > forward declaration.
>
> Since we forward ucmd now, ictx is in the ucmd so we need this
> structure for:
>
> - if (!IS_ERR(ret))
On Fri, May 23, 2025 at 01:51:25AM +, Tian, Kevin wrote:
> > If page is unmapped then stage 2 (Host page table) gets updated. IOMMU
> > will not
> > be able to find page and logs fault.
>
> As long as the fault is contained only for the relevant queue, yes
> we don't need another pinning from
On Thu, May 15, 2025 at 01:32:48PM -0700, Nicolin Chen wrote:
> On Thu, May 15, 2025 at 03:59:38PM -0300, Jason Gunthorpe wrote:
> > On Thu, May 15, 2025 at 11:16:45AM -0700, Nicolin Chen wrote:
> > > > I don't think this actually works like this without an unmap
> >
On Fri, May 16, 2025 at 04:08:25AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Friday, May 16, 2025 12:47 AM
> >
> > On Thu, May 08, 2025 at 08:02:35PM -0700, Nicolin Chen wrote:
> > > + /* vma->vm_pgoff carries an index to an mtree entry (
On Thu, May 15, 2025 at 07:05:45PM -0700, Nicolin Chen wrote:
> Otherwise, they would be something like:
> // in my_viommu_alloc()
> my_viommu = iommufd_viommu_alloc(ucmd, ...);
> iommufd_viommu_alloc_mmap(ucmd->ictx, my_viommu, ...);
> iommufd_viommu_destroy_mmap(ucmd->ict
On Fri, May 16, 2025 at 02:42:32AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Friday, May 16, 2025 12:06 AM
> >
> > Do we have way to make the pinning optional?
> >
> > As I understand AMD's system the iommu HW itself translates th
On Thu, May 15, 2025 at 01:17:47PM -0700, Nicolin Chen wrote:
> > I think the former is simpler to code, you can just add the req_type
> > to the signatures and if the driver comes back with a type != req_type
> > the core code will return EOPNOTSUPP
>
> OK.
>
> Maybe just turn the out_data_type
On Fri, May 16, 2025 at 04:30:23PM +0800, Yi Liu wrote:
> On 2025/5/5 22:18, Jason Gunthorpe wrote:
> > AMD IOMMU v1 is unique in supporting contiguous pages with a variable size
> > and it can decode the full 64 bit VA space. Unlike other x86 page tables
> > this explic
On Wed, May 14, 2025 at 04:08:09PM -0400, Alejandro Jimenez wrote:
>
>
> On 5/14/25 11:54 AM, Jason Gunthorpe wrote:
> > On Wed, May 14, 2025 at 09:23:49AM +, Ankit Soni wrote:
> > > I am experiencing a system hang with a 5-level v2 page table mode, on
> > >
hanged, 12 insertions(+)
Reviewed-by: Jason Gunthorpe
Jason
On Thu, May 15, 2025 at 12:21:17PM -0700, Nicolin Chen wrote:
> On Thu, May 15, 2025 at 03:56:29PM -0300, Jason Gunthorpe wrote:
> > On Thu, May 15, 2025 at 11:52:05AM -0700, Nicolin Chen wrote:
> > > On Thu, May 15, 2025 at 02:17:06PM -0300, Jason Gunthorpe wrote:
> > >
On Thu, May 15, 2025 at 11:16:45AM -0700, Nicolin Chen wrote:
> > As I understand AMD's system the iommu HW itself translates the
> > base_addr through the S2 page table automatically, so it doesn't need
> > pinned memory and physical addresses but just the IOVA.
>
> Right. That's why we invented
On Thu, May 15, 2025 at 11:52:05AM -0700, Nicolin Chen wrote:
> On Thu, May 15, 2025 at 02:17:06PM -0300, Jason Gunthorpe wrote:
> > On Thu, May 08, 2025 at 08:02:39PM -0700, Nicolin Chen wrote:
> > > Repurpose the @__reserved field in the struct iommu_hw_info_arm_smmu
t; Acked-by: Pranjal Shrivastava
> Signed-off-by: Nicolin Chen
> ---
> drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c | 13 +++--
> 1 file changed, 3 insertions(+), 10 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Thu, May 08, 2025 at 08:02:35PM -0700, Nicolin Chen wrote:
> +int _iommufd_alloc_mmap(struct iommufd_ctx *ictx, struct iommufd_object
> *owner,
> + phys_addr_t base, size_t length, unsigned long *offset)
> +{
> + struct iommufd_mmap *immap;
> + unsigned long startp;
/arm-smmu-v3/tegra241-cmdqv.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Thu, May 08, 2025 at 08:02:38PM -0700, Nicolin Chen wrote:
> An impl driver might want to allocate its own type of vIOMMU object or the
> standard IOMMU_VIOMMU_TYPE_ARM_SMMUV3 by setting up its own SW/HW bits, as
> the tegra241-cmdqv driver will add IOMMU_VIOMMU_TYPE_TEGRA241_CMDQV.
>
> Add a v
On Thu, May 08, 2025 at 08:02:39PM -0700, Nicolin Chen wrote:
> Repurpose the @__reserved field in the struct iommu_hw_info_arm_smmuv3,
> to an HW implementation-defined field @impl.
It would be nicer to have a tegra/cmdq specific struct and a way for
iommu_hw_info to select it. 'impl' isn't going
On Thu, May 08, 2025 at 08:02:33PM -0700, Nicolin Chen wrote:
> +/*
> + * Helpers for IOMMU driver to build/destroy a dependency between two sibling
> + * structures created by one of the allocators above
> + */
> +#define iommufd_hw_queue_depend(dependent, depended, member)
> \
On Thu, May 08, 2025 at 08:02:32PM -0700, Nicolin Chen wrote:
> +/**
> + * struct iommu_hw_queue_alloc - ioctl(IOMMU_HW_QUEUE_ALLOC)
> + * @size: sizeof(struct iommu_hw_queue_alloc)
> + * @flags: Must be 0
> + * @viommu_id: Virtual IOMMU ID to associate the HW queue with
> + * @type: One of enum io
On Thu, May 08, 2025 at 08:02:31PM -0700, Nicolin Chen wrote:
> +#define iommufd_hw_queue_alloc(viommu, drv_struct, member)
> \
> + ({ \
> + drv_struct *ret;
On Wed, May 14, 2025 at 12:21:37PM -0700, Nicolin Chen wrote:
> > Then when the command is over the core code either aborts or finalizes
> > the objects in the iommufd_ucmd. This way you don't have to expose
> > abort and related to drivers.
>
> I see! Do you want this to apply to the all objects
mu/iommufd/io_pagetable.h| 8 ++
> drivers/iommu/iommufd/iommufd_private.h | 6 ++
> drivers/iommu/iommufd/device.c | 117 ++--
> drivers/iommu/iommufd/io_pagetable.c| 95 +++
> 4 files changed, 117 insertions(+), 109 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
> }
> return &my_viommu->core;
> }
>
> Move iommufd_object_abort() to the driver.c file and the public header, to
> introduce common iommufd_struct_destroy() helper that will abort all kinds
> of driver structures, not confined to iommufd_viommu but also the n
of viommu allocations so it isn't such a big deal,
but just generally that is how it was built that the ictx comes from
the ioctl not the object.
Reviewed-by: Jason Gunthorpe
Jason
On Wed, May 14, 2025 at 09:23:49AM +, Ankit Soni wrote:
> I am experiencing a system hang with a 5-level v2 page table mode, on boot.
> The NVMe boot drive is not initializing.
> Below are the relevant dmesg logs with some prints i had added:
>
> [6.386439] AMD-Vi v2 domain init
> [6.3
On Wed, May 07, 2025 at 09:37:07AM +0700, Bagas Sanjaya wrote:
> On Mon, May 05, 2025 at 11:18:32AM -0300, Jason Gunthorpe wrote:
> > +Since each compilation unit can only access one underlying format at a
> > time,
> > +code that is intended to be generic across multiple f
On Tue, May 13, 2025 at 05:15:50AM +, Ankit Soni wrote:
> > +static int increase_top(struct pt_iommu *iommu_table, struct pt_range
> > *range,
> > + struct pt_iommu_map_args *map)
> > +{
> > + struct iommu_pages_list free_list = IOMMU_PAGES_LIST_INIT(free_list);
> > + str
1 - 100 of 285 matches
Mail list logo
