On Mon, Jun 16, 2025 at 12:53:40PM -0400, Demi Marie Obenour wrote:
> > AFAIK hyperv shows how to build something like this.
> Would this need KVM patches? I'm concerned that implementing this
> in userspace would interact badly with the irqfd fast path.
I don't know. I think you get the same is
_FILE")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Nicolin Chen
> ---
> tools/testing/selftests/iommu/iommufd_utils.h | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
disrupt its role. Mute the warning by force initializing the mfd
> and add an ASSERT_GT().
>
> Signed-off-by: Nicolin Chen
> ---
> tools/testing/selftests/iommu/iommufd.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
_FILE")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Nicolin Chen
> ---
> tools/testing/selftests/iommu/iommufd.c | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Jason Gunthorpe
Jason
On Sun, Jun 15, 2025 at 10:02:03PM -0700, Nicolin Chen wrote:
> FIXTURE_TEARDOWN(iommufd_dirty_tracking)
> {
> - munmap(self->buffer, variant->buffer_size);
> - munmap(self->bitmap, DIV_ROUND_UP(self->bitmap_size, BITS_PER_BYTE));
> + unsigned long size = variant->buffer_size;
> +
> +
On Sun, Jun 15, 2025 at 02:47:15PM -0400, Demi Marie Obenour wrote:
> Is a paravirtualized IOMMU with interrupt remapping something that makes
> sense?
IMHO linking interrupt remapping to the iommu is a poor design,
interrupt routing belongs in the irq subsystem, not in the iommu.
The fact AMD a
On Thu, Jun 12, 2025 at 12:03:14PM -0700, Nicolin Chen wrote:
> On Thu, Jun 12, 2025 at 03:56:13PM -0300, Jason Gunthorpe wrote:
> > On Thu, Jun 12, 2025 at 11:53:24AM -0700, Nicolin Chen wrote:
> > > @@ -2022,7 +2023,19 @@ FIXTURE_SETUP(iommufd_dirty_tracking)
> > >
On Thu, Jun 12, 2025 at 11:53:24AM -0700, Nicolin Chen wrote:
> @@ -2022,7 +2023,19 @@ FIXTURE_SETUP(iommufd_dirty_tracking)
> self->fd = open("/dev/iommu", O_RDWR);
> ASSERT_NE(-1, self->fd);
>
> - rc = posix_memalign(&self->buffer, HUGEPAGE_SIZE,
> variant->buffer_size);
>
quot;mm/huge_memory: add vmf_insert_folio_pud()")
> Signed-off-by: David Hildenbrand
> ---
> include/linux/mm.h | 19 -
> mm/huge_memory.c | 51 +-----
> 2 files changed, 46 insertions(+), 24 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
denbrand
> ---
> mm/huge_memory.c | 58 ++++++++
> 1 file changed, 39 insertions(+), 19 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
y.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Thu, Jun 12, 2025 at 05:23:01PM +0200, Thomas Weißschuh wrote:
> On Thu, Jun 12, 2025 at 11:58:01AM -0300, Jason Gunthorpe wrote:
> > On Thu, Jun 12, 2025 at 04:27:41PM +0200, Thomas Weißschuh wrote:
> >
> > > If the assumption is that this is most likely a kernel bu
On Thu, Jun 12, 2025 at 04:27:41PM +0200, Thomas Weißschuh wrote:
> If the assumption is that this is most likely a kernel bug,
> shouldn't it be fixed properly rather than worked around?
> After all the job of a selftest is to detect bugs to be fixed.
I investigated the history for a bit and it
On Wed, Jun 11, 2025 at 11:59:00PM -0700, Nicolin Chen wrote:
> We can see the 64MB was rounded up to 512MB by ksys_mmap_pgoff()
> when being passed in to hugetlb_file_setup() at:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/mmap.c?h=v6.16-rc1#n594
> " l
On Wed, Jun 11, 2025 at 04:43:00PM -0700, Nicolin Chen wrote:
> So, the test case sets an alignment with HUGEPAGE_SIZE=512MB while
> allocating buffer_size=64MB:
> rc = posix_memalign(&self->buffer, HUGEPAGE_SIZE, variant->buffer_size);
> vrc = mmap(self->buffer, variant->buffer_size, P
On Tue, Jun 10, 2025 at 11:48:44AM -0700, Nicolin Chen wrote:
> On Tue, Jun 10, 2025 at 09:09:02AM -0300, Jason Gunthorpe wrote:
> > On Tue, Jun 10, 2025 at 01:38:22PM +0200, Thomas Weißschuh wrote:
> > > >
On Tue, Jun 10, 2025 at 01:38:22PM +0200, Thomas Weißschuh wrote:
> Hi Nicolin,
>
> On Mon, Jun 09, 2025 at 11:49:05PM -0700, Nicolin Chen wrote:
> > CC += Jason
> >
> > On Mon, May 05, 2025 at 05:15:27PM +0200, Thomas Weißschuh wrote:
> > > To get rid of setjmp()/longjmp(), the teardown logic ne
On Sat, May 10, 2025 at 10:51:58PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 10/5/25 08:07, Jason Gunthorpe wrote:
> > On Fri, May 09, 2025 at 12:57:18PM +1000, Alexey Kardashevskiy wrote:
> > >
> > >
> > > On 7/5/25 22:24, Jason Gunthorpe wrote:
On Fri, May 09, 2025 at 12:57:18PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 7/5/25 22:24, Jason Gunthorpe wrote:
> > On Wed, May 07, 2025 at 09:18:29PM +1000, Alexey Kardashevskiy wrote:
> >
> > > > We should not destroy the vdevice for something like that
On Wed, May 07, 2025 at 09:18:29PM +1000, Alexey Kardashevskiy wrote:
> > We should not destroy the vdevice for something like that. In a CC
> > case that would unplug it from the VM which is not right.
>
> vdevice is not directly seen by the guest, is not it? The guest will
> see, for example, a
On Tue, May 06, 2025 at 12:55:02PM -0700, Nicolin Chen wrote:
> On Tue, May 06, 2025 at 09:58:47AM -0300, Jason Gunthorpe wrote:
> > On Mon, May 05, 2025 at 07:53:44PM -0700, Nicolin Chen wrote:
> > > On Mon, May 05, 2025 at 02:08:07PM -0300, Jason Gunthorpe wrote:
> > >
On Mon, May 05, 2025 at 07:53:44PM -0700, Nicolin Chen wrote:
> On Mon, May 05, 2025 at 02:08:07PM -0300, Jason Gunthorpe wrote:
> > On Wed, Apr 30, 2025 at 12:58:47AM -0700, Nicolin Chen wrote:
> >
> > > > ... and I just hit a problem with it - this is basically gues
On Wed, Apr 30, 2025 at 12:58:47AM -0700, Nicolin Chen wrote:
> > ... and I just hit a problem with it - this is basically guest BDFn
> > and it works as long as I'm hotplugging the TEE-IO VF into an SNP VM
> > but does not when I pass through via the QEMU cmdline - bus numbers
> > are not assigne
On Thu, Feb 27, 2025 at 09:46:55AM -0800, Nicolin Chen wrote:
> I found a bit confusing to use "owner" as the domain->owner isn't
> the same thing in this context. Maybe it should be "driver_ops"?
Maybe, but I wouldn't churn it
> Then, "owner" could be another op structure that holds the owner-
>
On Wed, Feb 19, 2025 at 05:31:41PM -0800, Nicolin Chen wrote:
> + cur = kzalloc(sizeof(*cur), GFP_KERNEL);
> + if (!cur)
> + cur = ERR_PTR(-ENOMEM);
> + cur->sw_msi_start = sw_msi_start;
> + cur->msi_addr = msi_addr;
> + cur->pgoff = max
On Thu, Feb 27, 2025 at 11:21:28AM +, Robin Murphy wrote:
> It wouldn't need a hard dependency, it's easy to have a trivial built-in
> stub function which becomes valid once the module loads - you literally have
> the iommufd_driver infrastructure for precisely that sort of thing already.
Yes
On Wed, Feb 26, 2025 at 10:57:00AM -0800, Nicolin Chen wrote:
> OK, I see. But we are also changing the behavior for the
> !CONFIG_IOMMU_DMA configuration, in which case all other iommu
> functions seem to return -ENODEV. And I assume we would need a
> justification for such a change?
>
> Perhaps,
On Tue, Feb 25, 2025 at 06:25:27PM -0800, Nicolin Chen wrote:
> On Fri, Feb 21, 2025 at 10:39:59AM -0400, Jason Gunthorpe wrote:
> > diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> > index 99dd72998cb7f7..082274e8ba6a3d 100644
> > --- a/include/linux/iommu.h
&g
On Fri, Feb 21, 2025 at 03:39:45PM +, Robin Murphy wrote:
> Yuck. Realistically we are going to have no more than two different
> implementations of this; a fiddly callback interface seems overkill. All we
> should need in the domain is a simple indicator of *which* MSI translation
> scheme is
On Fri, Feb 21, 2025 at 03:23:22PM +, Robin Murphy wrote:
> Eww... What's the issue with just checking the domain type in
> iommu_put_dma_cookie()? Is is that IOMMUFD and VFIO type 1 are both doing
> their own different thing with IOMMU_DOMAIN_UNMANAGED?
Yes
> In general it seems like a bad s
On Wed, Feb 19, 2025 at 05:31:35PM -0800, Nicolin Chen wrote:
>
> Jason Gunthorpe (5):
> genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of
> iommu_cookie
> genirq/msi: Refactor iommu_dma_compose_msi_msg()
> iommu: Make iommu_dma_prepare_msi() into a
On Wed, Feb 19, 2025 at 05:31:41PM -0800, Nicolin Chen wrote:
> +/*
> + * Get a iommufd_sw_msi_map for the msi physical address requested by the irq
> + * layer. The mapping to IOVA is global to the iommufd file descriptor, every
> + * domain that is attached to a device using the same MSI paramet
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -154,7 +154,6 @@ config IOMMU_DMA
> select DMA_OPS_HELPERS
> select IOMMU_API
> select IOMMU_IOVA
> - select IRQ_MSI_IOMMU
> select NEED_SG_DMA_LENGTH
> select NEED_SG_DMA_FLAGS if SWIOTLB
Because of
y the
> entity that allocated the domain. Note that legacy vfio type1 flows
> continue to use dma-iommu.c for sw_msi and still need iova_cookie.
>
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Nicolin Chen
> ---
> include/linux/iommu.h | 2 +-
> 1 file changed, 1 insertion(
On Fri, Feb 21, 2025 at 10:28:20AM +0100, Thomas Gleixner wrote:
> On Wed, Feb 19 2025 at 17:31, Nicolin Chen wrote:
> > Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA
> > address is already known during iommu_dma_prepare_msi() and cannot change.
> > Thus, it can simply
> using the IOMMU group mutex.
> >
> > "A following patch" has no meaning once the current one is
> > applied. Simply say:
> >
> > The other UAF in iommu_get_domain_for_dev() will be addressed
> > seperately, by
> >
> > >
y the
> entity that allocated the domain. Note that legacy vfio type1 flows
> continue to use dma-iommu.c for sw_msi and still need iova_cookie.
>
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Nicolin Chen
> ---
> include/linux/iommu.h | 2 +-
> 1 file changed, 1 inse
+-
> drivers/iommu/iommufd/hw_pagetable.c | 2 +-
> 3 files changed, 6 insertions(+), 4 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Sat, Feb 08, 2025 at 01:02:33AM -0800, Nicolin Chen wrote:
> iommu: Turn iova_cookie to dma-iommu private pointer
I suggest you respin this with the updates and stop here at this
patch, it is enough to get the core infrastructure updated and does
not bring any uAPI changes. The remainder can
On Thu, Feb 13, 2025 at 01:11:37PM +0100, Thomas Gleixner wrote:
> On Sat, Feb 08 2025 at 01:02, Nicolin Chen wrote:
>
> > From: Jason Gunthorpe
> >
> > The new function is used to take in a u64 MSI address and store it in the
Assuming Nicolin moves the hunk as I sugges
On Thu, Feb 13, 2025 at 12:54:15PM +0100, Thomas Gleixner wrote:
> So this change log really fails to follow the basic structure:
>
>The context, the problem and the solution
The IOMMU translation for MSI message addresses is a two step
process, seperated in time:
1) iommu_dma_prepare_msi()
On Sat, Feb 08, 2025 at 01:02:39AM -0800, Nicolin Chen wrote:
> +static struct iommufd_attach_handle *
> +iommu_group_get_iommufd_handle(struct iommu_group *group)
> +{
> + struct iommu_attach_handle *handle;
> +
> + handle = iommu_attach_handle_get(group, IOMMU_NO_PASID, 0);
> + if (I
On Sat, Feb 08, 2025 at 01:02:41AM -0800, Nicolin Chen wrote:
> @@ -433,8 +433,8 @@ static int iommufd_group_setup_msi(struct iommufd_group
> *igroup,
> list_for_each_entry(cur, &ictx->sw_msi_list, sw_msi_item) {
> int rc;
>
> - if (cur->sw_msi_start != igroup->sw
On Fri, Feb 07, 2025 at 10:59:48AM -0800, Nicolin Chen wrote:
> On Fri, Feb 07, 2025 at 11:28:01AM -0400, Jason Gunthorpe wrote:
> > On Fri, Feb 07, 2025 at 10:30:20AM -0400, Jason Gunthorpe wrote:
> > > On Thu, Feb 06, 2025 at 08:26:05PM -0800, Nicolin Chen wrote:
&g
On Fri, Feb 07, 2025 at 10:30:20AM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 06, 2025 at 08:26:05PM -0800, Nicolin Chen wrote:
> > Yea, I found iopt_reserve_iova() is actually missed entirely...
> >
> > While fixing this, I see a way to turn the OPTIONs back to per-
&
On Fri, Jan 10, 2025 at 07:32:16PM -0800, Nicolin Chen wrote:
> Though these two approaches feel very different on the surface, they can
> share some underlying common infrastructure. Currently, only one pair of
> sw_msi functions (prepare/compose) are provided by dma-iommu for irqchip
> drivers to
On Thu, Feb 06, 2025 at 08:26:05PM -0800, Nicolin Chen wrote:
> Yea, I found iopt_reserve_iova() is actually missed entirely...
>
> While fixing this, I see a way to turn the OPTIONs back to per-
> idev, if you still prefer them to be per-idev(?). Then, we can
> check a given input in the set_opti
On Tue, Feb 04, 2025 at 01:55:01PM +0100, Eric Auger wrote:
> OK so you need to set host sw_msi_start to the guest doorbell GPA which
> is currently set, in qemu, at
> GITS_TRANSLATER 0x0808 + 0x1
Yes (but don't do this except for testing)
The challenge that remains is how to build an AP
On Wed, Jan 29, 2025 at 06:49:22PM +0100, Eric Auger wrote:
> > If it was overriden inside iommufd then the user told the kernel what
> > range to use to override it. I don't need to go back and report back
> > to userspace information that it already gave to the kernel..
>
> Looks strange to me b
On Wed, Jan 29, 2025 at 06:46:20PM +0100, Eric Auger wrote:
> >>> This missing peice is cleaning up the ITS mapping to allow for
> >>> multiple ITS pages. I've imagined that kvm would someone give iommufd
> >>> a FD that holds the specific ITS pages instead of the
> >>> IOMMU_OPTION_SW_MSI_START/SI
On Wed, Jan 29, 2025 at 06:23:33PM +0100, Eric Auger wrote:
> >> IIUC the MSI window will then be different when using legacy VFIO
> >> assignment and iommufd backend.
> > ? They use the same, iommufd can have userspace override it. Then it
> > will ignore the reserved region.
> In current arm-smmu
On Wed, Jan 29, 2025 at 03:54:48PM +0100, Eric Auger wrote:
> >> or you are just mentioning it here because
> >> it is still possible to make use of that. I think from previous
> >> discussions the
> >> argument was to adopt a more dedicated MSI pass-through model which I
> >> think is approach-2
On Wed, Jan 29, 2025 at 02:44:12PM +0100, Eric Auger wrote:
> Hi,
>
>
> On 1/11/25 4:32 AM, Nicolin Chen wrote:
> > For systems that require MSI pages to be mapped into the IOMMU translation
> > the IOMMU driver provides an IOMMU_RESV_SW_MSI range, which is the default
> > recommended IOVA window
On Fri, Jan 10, 2025 at 07:32:23PM -0800, Nicolin Chen wrote:
> +/*
> + * FIXME: when a domain is removed any ids that are not in the union of
> + * all still attached devices should be removed.
> + */
I've been thinking about this, maybe we can just delete the comment.
It is thinking about is t
On Thu, Jan 23, 2025 at 06:10:54PM +0100, Eric Auger wrote:
> > -/**
> > - * iommu_dma_compose_msi_msg() - Apply translation to an MSI message
> > - * @desc: MSI descriptor prepared by iommu_dma_prepare_msi()
> > - * @msg: MSI message containing target physical address
> > - */
> > -static inline
On Thu, Jan 23, 2025 at 06:10:48PM +0100, Eric Auger wrote:
> > However iommufd now permits the domain to change while the driver is
> > probed and VFIO userspace can create races with IRQ changes calling
> > iommu_dma_prepare/compose_msi_msg() and changing/freeing the iommu_domain.
> and is it sa
On Thu, Jan 23, 2025 at 06:10:47PM +0100, Eric Auger wrote:
> Hi,
>
>
> On 1/11/25 4:32 AM, Nicolin Chen wrote:
> > From: Jason Gunthorpe
> >
> > SW_MSI supports IOMMU to translate an MSI message before the MSI message
> > is delivered to the inter
On Thu, Jan 23, 2025 at 09:54:38AM +, Tian, Kevin wrote:
> > From: Nicolin Chen
> > Sent: Saturday, January 11, 2025 11:32 AM
> >
> > @@ -224,8 +224,10 @@ struct iommu_domain {
> > phys_addr_t msi_addr);
> > #endif
> >
> > - void *fault_data;
> > - union {
> > + unio
On Thu, Jan 23, 2025 at 09:06:49AM +, Shameerali Kolothum Thodi wrote:
> One confusion I have about the above text is, do we still plan to support the
> approach -1( Using RMR in Qemu)
Yes, it remains an option. The VMM would use the
IOMMU_OPTION_SW_MSI_START/SIZE ioctls to tell the kernel wh
On Sat, Jan 18, 2025 at 12:32:49PM -0800, Nicolin Chen wrote:
> On Sat, Jan 18, 2025 at 04:23:22PM +0800, Yi Liu wrote:
> > On 2025/1/11 11:32, Nicolin Chen wrote:
> > > "attach_handle" was added exclusively for the iommufd_fault_iopf_handler()
> > > used by IOPF/PRI use cases, along with the "faul
On Tue, Jan 14, 2025 at 11:21:13PM -0500, Yury Norov wrote:
> > +static int iommufd_sw_msi_install(struct iommufd_ctx *ictx,
> > + struct iommufd_hwpt_paging *hwpt_paging,
> > + struct iommufd_sw_msi_map *msi_map)
> > +{
> > + unsigned long
On Fri, Jan 10, 2025 at 07:32:24PM -0800, Nicolin Chen wrote:
> Now, iommufd has its own iommufd_sw_msi using iommufd_hwpt, the iommufd
> owned domain's private pointer. Similarly, iova_cookie can be seen as a
> dma-iommu owned domain's private pointer. So, move iova_cookie into the
> union.
This
On Tue, Dec 03, 2024 at 12:02:53AM -0800, Nicolin Chen wrote:
> There are a few patches in vIRQ series that rework the fault.c file. So,
> we should fix this before that bigger series touches the same code.
>
> And add missing coverage for IOMMU_FAULT_QUEUE_ALLOC in iommufd_fail_nth.
>
> Thanks!
On Tue, Oct 29, 2024 at 09:05:14PM -0700, Nicolin Chen wrote:
> On Tue, Oct 29, 2024 at 03:55:58PM -0300, Jason Gunthorpe wrote:
> > On Tue, Oct 29, 2024 at 09:18:05AM -0700, Nicolin Chen wrote:
> > > I think we'd need the same change in iommufd_object_abort() too.
>
On Tue, Oct 29, 2024 at 12:30:00PM -0700, Nicolin Chen wrote:
> > iommufd_device_unbind() can't fail, and if the object can't be
> > destroyed because it has an elevated long term refcount it WARN's:
> >
> >
> > ret = iommufd_object_remove(ictx, obj, obj->id, REMOVE_WAIT_SHORTTERM);
> >
> >
On Tue, Oct 29, 2024 at 09:18:05AM -0700, Nicolin Chen wrote:
> On Tue, Oct 29, 2024 at 11:49:07AM -0300, Jason Gunthorpe wrote:
> > On Fri, Oct 25, 2024 at 04:49:43PM -0700, Nicolin Chen wrote:
> > > To support driver-allocated vIOMMU objects, it's suggested to call the
&g
On Tue, Oct 29, 2024 at 10:29:56AM -0700, Nicolin Chen wrote:
> On Tue, Oct 29, 2024 at 12:58:24PM -0300, Jason Gunthorpe wrote:
> > On Fri, Oct 25, 2024 at 04:50:30PM -0700, Nicolin Chen wrote:
> > > diff --git a/drivers/iommu/iommufd/device.c
> > > b/drivers/iommu/i
On Fri, Oct 25, 2024 at 04:50:34PM -0700, Nicolin Chen wrote:
> @@ -497,17 +497,35 @@ int iommufd_hwpt_invalidate(struct iommufd_ucmd *ucmd)
> goto out;
> }
>
> - hwpt = iommufd_get_hwpt_nested(ucmd, cmd->hwpt_id);
> - if (IS_ERR(hwpt)) {
> - rc = PTR_ERR(h
On Tue, Oct 29, 2024 at 09:07:38AM -0700, Nicolin Chen wrote:
> On Tue, Oct 29, 2024 at 12:27:46PM -0300, Jason Gunthorpe wrote:
> > On Mon, Oct 28, 2024 at 07:52:10AM -0700, Nicolin Chen wrote:
> > > On Mon, Oct 28, 2024 at 10:03:09AM -0300, Jason Gunthor
On Tue, Oct 29, 2024 at 09:02:58AM -0700, Nicolin Chen wrote:
> On Tue, Oct 29, 2024 at 12:34:38PM -0300, Jason Gunthorpe wrote:
> > On Fri, Oct 25, 2024 at 04:49:49PM -0700, Nicolin Chen wrote:
> > > For an iommu_dev that can unplug (so far only this selftest does so), the
>
On Tue, Oct 29, 2024 at 11:54:36AM -0300, Jason Gunthorpe wrote:
> On Fri, Oct 25, 2024 at 04:49:44PM -0700, Nicolin Chen wrote:
> > +void iommufd_viommu_destroy(struct iommufd_object *obj)
> > +{
> > + struct iommufd_viommu *viommu =
> > + container_of(obj,
On Tue, Oct 29, 2024 at 08:22:43AM +, Tian, Kevin wrote:
> > From: Nicolin Chen
> > Sent: Saturday, October 26, 2024 7:51 AM
> >
> > @@ -302,7 +302,9 @@ iommufd_viommu_alloc_hwpt_nested(struct
> > iommufd_viommu *viommu, u32 flags,
> > }
> > hwpt->domain->owner = viommu->iommu_dev->op
gt; ---
> drivers/iommu/iommufd/hw_pagetable.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Jason Gunthorpe
Jason
On Fri, Oct 25, 2024 at 04:49:45PM -0700, Nicolin Chen wrote:
> Allow IOMMU driver to use a vIOMMU object that holds a nesting parent
> hwpt/domain to allocate a nested domain.
>
> Suggested-by: Jason Gunthorpe
> Reviewed-by: Kevin Tian
> Signed-off-by: Nicolin Chen
>
On Tue, Oct 29, 2024 at 08:46:40AM -0700, Nicolin Chen wrote:
> On Tue, Oct 29, 2024 at 12:36:24PM -0300, Jason Gunthorpe wrote:
> > On Tue, Oct 29, 2024 at 11:54:36AM -0300, Jason Gunthorpe wrote:
> > > On Fri, Oct 25, 2024 at 04:49:44PM -0700, Nicolin Chen wr
y: Nicolin Chen
> ---
> tools/testing/selftests/iommu/iommufd_utils.h | 27 +++
> tools/testing/selftests/iommu/iommufd.c | 20 ++
> .../selftests/iommu/iommufd_fail_nth.c| 4 +++
> 3 files changed, 51 insertions(+)
Reviewed-by: Jason Gunthorpe
Jason
On Fri, Oct 25, 2024 at 04:50:30PM -0700, Nicolin Chen wrote:
> +/**
> + * struct iommu_vdevice_alloc - ioctl(IOMMU_VDEVICE_ALLOC)
> + * @size: sizeof(struct iommu_vdevice_alloc)
> + * @viommu_id: vIOMMU ID to associate with the virtual device
> + * @dev_id: The pyhsical device to allocate a virtua
-
> drivers/iommu/iommufd/iommufd_test.h | 2 +
> drivers/iommu/iommufd/selftest.c | 64
> 2 files changed, 66 insertions(+)
Reviewed-by: Jason Gunthorpe
Jason
--
> 1 file changed, 24 insertions(+), 8 deletions(-)
Reviewed-by: Jason Gunthorpe
Since this is built into the iommufd module it can't be unloaded
without also unloading iommufd, which is impossible as long as any
iommufd FDs are open. So I expect that the WARN_ON can never happen.
Jason
fd/selftest.c | 89 ++--
> 1 file changed, 50 insertions(+), 39 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
Signed-off-by: Nicolin Chen
> ---
> drivers/iommu/iommufd/selftest.c | 75 ++--
> 1 file changed, 42 insertions(+), 33 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Mon, Oct 28, 2024 at 07:52:10AM -0700, Nicolin Chen wrote:
> On Mon, Oct 28, 2024 at 10:03:09AM -0300, Jason Gunthorpe wrote:
> > On Mon, Oct 28, 2024 at 11:24:10AM +0800, Zhangfei Gao wrote:
> >
> > > > +/**
> > > > + * iommufd_viommu_alloc_hwpt_ne
On Fri, Oct 25, 2024 at 04:49:44PM -0700, Nicolin Chen wrote:
> +void iommufd_viommu_destroy(struct iommufd_object *obj)
> +{
> + struct iommufd_viommu *viommu =
> + container_of(obj, struct iommufd_viommu, obj);
> +
> + if (viommu->ops && viommu->ops->free)
> + viom
On Fri, Oct 25, 2024 at 04:49:43PM -0700, Nicolin Chen wrote:
> To support driver-allocated vIOMMU objects, it's suggested to call the
> allocator helper in IOMMU dirvers. However, there is no guarantee that
> drivers will all use it and allocate objects properly.
>
> Add a helper for iommufd core
> .viommu_alloc = my_driver_viommu_alloc,
> };
>
> To make the Kernel config work between a driver and the iommufd core, move
> the _iommufd_object_alloc helper into a new driver.c file that builds with
> CONFIG_IOMMUFD_DRIVER.
>
> Suggested-by: Jason G
> > to
> > a Context Table. This virt_id helps IOMMU drivers to link the vID to a pID
> > of the device against the physical IOMMU instance. This is essential for a
> > vIOMMU-based invalidation, where the request contains a device's vID for a
> > device cache flush, e.g. ATC invalidation.
>
> pro
On Mon, Oct 28, 2024 at 11:24:10AM +0800, Zhangfei Gao wrote:
> > +/**
> > + * iommufd_viommu_alloc_hwpt_nested() - Get a hwpt_nested for a vIOMMU
> > + * @viommu: vIOMMU ojbect to associate the hwpt_nested/domain with
> > + * @user_data: user_data pointer. Must be valid
> > + *
> > + * Allocate a
On Wed, Oct 23, 2024 at 11:54:54AM -0700, Nicolin Chen wrote:
> > The iopf detatch function will act as a barrirer to ensure that all
> > the async work has completed, sort of like how RCU works.
>
> The xa_lock(&group->pasid_array) is released once the handle is
> returned to the iommu_attach_han
On Fri, Oct 25, 2024 at 06:53:01PM +1100, Alexey Kardashevskiy wrote:
> > +#define iommufd_vdevice_alloc(ictx, drv_struct, member)
> > \
> > + ({ \
> > + static_assert(
On Fri, Oct 25, 2024 at 08:34:05AM +, Tian, Kevin wrote:
> > The vIOMMU object should be seen as a slice of a physical IOMMU instance
> > that is passed to or shared with a VM. That can be some HW/SW resources:
> > - Security namespace for guest owned ID, e.g. guest-controlled cache tags
> >
On Fri, Oct 25, 2024 at 09:18:05AM +, Tian, Kevin wrote:
> > From: Nicolin Chen
> > Sent: Tuesday, October 22, 2024 8:20 AM
> >
> > Add a new driver-type for ARM SMMUv3 to enum iommu_viommu_type.
> > Implement
> > an arm_vsmmu_alloc() with its viommu op
> > arm_vsmmu_domain_alloc_nested(),
>
On Fri, Oct 25, 2024 at 08:47:40AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, October 22, 2024 9:16 PM
> >
> > On Tue, Oct 22, 2024 at 04:59:07PM +0800, Baolu Lu wrote:
> >
> > > Is it feasible to make vIOMMU object more gener
On Thu, Oct 24, 2024 at 11:14:21PM -0700, Nicolin Chen wrote:
> On Fri, Oct 25, 2024 at 04:58:33PM +1100, Alexey Kardashevskiy wrote:
> > > > > > Is there any real example of a .vdevice_alloc hook, besides the
> > > > > > selftests? It is not in iommufd_viommu_p2-v4-with-rmr, hence the
> > > > > >
On Wed, Oct 23, 2024 at 12:22:15AM -0700, Nicolin Chen wrote:
> On Thu, Sep 05, 2024 at 03:01:19PM -0300, Jason Gunthorpe wrote:
> > On Tue, Aug 27, 2024 at 10:02:06AM -0700, Nicolin Chen wrote:
> > > The iommufd core provides a lookup helper for an IOMMU driver to find a
>
On Tue, Oct 22, 2024 at 04:59:07PM +0800, Baolu Lu wrote:
> Is it feasible to make vIOMMU object more generic, rather than strictly
> tying it to nested translation? For example, a normal paging domain that
> translates gPAs to hPAs could also have a vIOMMU object associated with
> it.
>
> While
On Sat, Oct 19, 2024 at 06:42:30PM -0700, Nicolin Chen wrote:
> > But be mindful of this abort, it doesn't want to be inside the lock if
> > it also gets the lock.. fail_nth should be updated to cover these new
> > ioctls to look for tricky things like that
>
> I added an abort() beside destroy():
On Sat, Oct 19, 2024 at 06:35:45PM -0700, Nicolin Chen wrote:
> On Thu, Oct 17, 2024 at 03:45:56PM -0300, Jason Gunthorpe wrote:
> > > +struct iommufd_vdevice *
> > > +__iommufd_vdevice_alloc(struct iommufd_ctx *ictx, size_t size)
> > > +{
> > > + struct
On Mon, Oct 21, 2024 at 07:11:47PM +1100, Alexey Kardashevskiy wrote:
> > + hwpt_paging = iommufd_get_hwpt_paging(ucmd, cmd->hwpt_id);
> > + if (IS_ERR(hwpt_paging)) {
> > + rc = PTR_ERR(hwpt_paging);
>
>
> iommufd_get_hwpt_paging() is container_of() which does not test for the
> va
On Thu, Oct 17, 2024 at 03:11:10PM -0400, Peter Xu wrote:
> On Thu, Oct 17, 2024 at 02:10:10PM -0300, Jason Gunthorpe wrote:
> > > If so, maybe that's a non-issue for non-CoCo, where the VM object /
> > > gmemfd object (when created) can have a flag marking that it
On Wed, Oct 09, 2024 at 09:38:12AM -0700, Nicolin Chen wrote:
> Following the previous vIOMMU series, this adds another vDEVICE structure,
> representing the association from an iommufd_device to an iommufd_viommu.
> This gives the whole architecture a new "v" layer:
Don't thread series together l
1 - 100 of 1494 matches
Mail list logo
