All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pranjal Shrivastava <praan@google.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: jgg@nvidia.com, kevin.tian@intel.com, corbet@lwn.net,
	will@kernel.org, bagasdotme@gmail.com, robin.murphy@arm.com,
	joro@8bytes.org, thierry.reding@gmail.com, vdumpa@nvidia.com,
	jonathanh@nvidia.com, shuah@kernel.org, jsnitsel@redhat.com,
	nathan@kernel.org, peterz@infradead.org, yi.l.liu@intel.com,
	mshavit@google.com, zhangzekun11@huawei.com,
	iommu@lists.linux.dev, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-tegra@vger.kernel.org, linux-kselftest@vger.kernel.org,
	patches@lists.linux.dev, mochs@nvidia.com,
	alok.a.tiwari@oracle.com, vasant.hegde@amd.com,
	dwmw2@infradead.org, baolu.lu@linux.intel.com
Subject: Re: [PATCH v7 27/28] iommu/tegra241-cmdqv: Add user-space use support
Date: Wed, 2 Jul 2025 01:38:33 +0000	[thread overview]
Message-ID: <aGSNmf5Q82xEbDpX@google.com> (raw)
In-Reply-To: <aGSBTpY0nkdp2TTL@Asurada-Nvidia>

On Tue, Jul 01, 2025 at 05:46:06PM -0700, Nicolin Chen wrote:
> On Wed, Jul 02, 2025 at 12:14:28AM +0000, Pranjal Shrivastava wrote:
> > Thus, coming back to the two initial points:
> > 
> > 1) Issuing "non-invalidation" commands through .cache_invalidate could
> >    be confusing, I'm not asking to change the op name here, but if we
> >    plan to label it, let's label them as "Trapped commands" OR
> >    "non-accelerated" commands as you suggested.
> 
> VCMDQ only accelerates limited invalidation commands, not all of
> them: STE cache invalidation and CD cache invalidation commands
> still go down to that op.
> 

Right, I'm just saying the "other" non-accelerated commands that are
NOT invalidations also go down that op. So, if we add a comment, let's 
not call them "non-invalidation" commands.

> > 2) The "FIXME" confusion: The comment in arm_vsmmu_cache_invalidate
> >    mentions we'd like to "fix" the issuing of commands through the main
> >    cmdq and instead like to group by "type", if that "type" is the queue
> >    type (which I assume it is because IOMMU_TYPE has to be arm-smmu-v3),
> 
> I recall that FIXME is noted by Jason at that time. And it should
> be interpreted as "group by opcode", IIUIC.

I see.. I misunderstood that..

> 
> The thing is that for a host kernel that enabled in-kernel VCMDQs,
> those trapped user commands can be just issued to the smmu->cmdq
> or a vcmdq (picked via the get_secondary_cmdq impl_op).
> 

Ohh.. so maybe some sort of a load balancing thing?

> >    what do we plan to do differently there, given that the op is only
> >    for trapped commands *have* to go through the main CMDQ?
> 
> If we do something differently there, it could just do a one-time
> get_secondary_cmdq call to pick a in-kernel vcmdq over smmu->cmdq
> to fill in all the trapped commands.
> 

Alright.

> And this is not related to this series at all.

Agreed, sorry for the confusion then.. I thought that the "type" meant
the queue type.. I guess it's all done then. I have no further questions

Thanks for the clarification!

> 
> Nicolin

Praan


  reply	other threads:[~2025-07-02  1:41 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-26 19:34 [PATCH v7 00/28] iommufd: Add vIOMMU infrastructure (Part-4 HW QUEUE) Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 01/28] iommufd: Report unmapped bytes in the error path of iopt_unmap_iova_range Nicolin Chen
2025-07-02  9:39   ` Tian, Kevin
2025-07-04 12:59   ` Jason Gunthorpe
2025-06-26 19:34 ` [PATCH v7 02/28] iommufd/viommu: Explicitly define vdev->virt_id Nicolin Chen
2025-07-01 12:30   ` Pranjal Shrivastava
2025-07-02  9:40   ` Tian, Kevin
2025-07-02 19:59     ` Nicolin Chen
2025-07-04 12:59   ` Jason Gunthorpe
2025-06-26 19:34 ` [PATCH v7 03/28] iommu: Use enum iommu_hw_info_type for type in hw_info op Nicolin Chen
2025-07-01 12:48   ` Pranjal Shrivastava
2025-07-01 12:51   ` Pranjal Shrivastava
2025-07-02  9:41   ` Tian, Kevin
2025-07-04 13:00   ` Jason Gunthorpe
2025-06-26 19:34 ` [PATCH v7 04/28] iommu: Add iommu_copy_struct_to_user helper Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 05/28] iommu: Pass in a driver-level user data structure to viommu_init op Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 06/28] iommufd/viommu: Allow driver-specific user data for a vIOMMU object Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 07/28] iommufd/selftest: Support user_data in mock_viommu_alloc Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 08/28] iommufd/selftest: Add coverage for viommu data Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 09/28] iommufd/access: Add internal APIs for HW queue to use Nicolin Chen
2025-07-02  9:42   ` Tian, Kevin
2025-07-04 13:08   ` Jason Gunthorpe
2025-06-26 19:34 ` [PATCH v7 10/28] iommufd/access: Bypass access->ops->unmap for internal use Nicolin Chen
2025-07-02  9:45   ` Tian, Kevin
2025-07-02 20:12     ` Nicolin Chen
2025-07-03  4:57       ` Tian, Kevin
2025-07-04  4:08         ` Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 11/28] iommufd/viommu: Add driver-defined vDEVICE support Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 12/28] iommufd/viommu: Introduce IOMMUFD_OBJ_HW_QUEUE and its related struct Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 13/28] iommufd/viommu: Add IOMMUFD_CMD_HW_QUEUE_ALLOC ioctl Nicolin Chen
2025-07-04 13:26   ` Jason Gunthorpe
2025-07-04 13:33     ` Jason Gunthorpe
2025-06-26 19:34 ` [PATCH v7 14/28] iommufd/driver: Add iommufd_hw_queue_depend/undepend() helpers Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 15/28] iommufd/selftest: Add coverage for IOMMUFD_CMD_HW_QUEUE_ALLOC Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 16/28] iommufd: Add mmap interface Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 17/28] iommufd/selftest: Add coverage for the new " Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 18/28] Documentation: userspace-api: iommufd: Update HW QUEUE Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 19/28] iommu: Allow an input type in hw_info op Nicolin Chen
2025-07-01 12:54   ` Pranjal Shrivastava
2025-06-26 19:34 ` [PATCH v7 20/28] iommufd: Allow an input data_type via iommu_hw_info Nicolin Chen
2025-07-01 12:58   ` Pranjal Shrivastava
2025-06-26 19:34 ` [PATCH v7 21/28] iommufd/selftest: Update hw_info coverage for an input data_type Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 22/28] iommu/arm-smmu-v3-iommufd: Add vsmmu_size/type and vsmmu_init impl ops Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 23/28] iommu/arm-smmu-v3-iommufd: Add hw_info to impl_ops Nicolin Chen
2025-07-01 12:24   ` Pranjal Shrivastava
2025-06-26 19:34 ` [PATCH v7 24/28] iommu/tegra241-cmdqv: Use request_threaded_irq Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 25/28] iommu/tegra241-cmdqv: Simplify deinit flow in tegra241_cmdqv_remove_vintf() Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 26/28] iommu/tegra241-cmdqv: Do not statically map LVCMDQs Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 27/28] iommu/tegra241-cmdqv: Add user-space use support Nicolin Chen
2025-07-01 16:02   ` Pranjal Shrivastava
2025-07-01 19:42     ` Nicolin Chen
2025-07-01 20:03       ` Pranjal Shrivastava
2025-07-01 20:23         ` Nicolin Chen
2025-07-01 20:43           ` Pranjal Shrivastava
2025-07-01 22:07             ` Nicolin Chen
2025-07-01 22:51               ` Pranjal Shrivastava
2025-07-01 23:01                 ` Nicolin Chen
2025-07-02  0:14                   ` Pranjal Shrivastava
2025-07-02  0:46                     ` Nicolin Chen
2025-07-02  1:38                       ` Pranjal Shrivastava [this message]
2025-07-02 18:05                         ` Jason Gunthorpe
2025-07-03 14:46                           ` Pranjal Shrivastava
2025-07-03 17:55                             ` Jason Gunthorpe
2025-07-03 18:48                               ` Pranjal Shrivastava
2025-07-04 12:50                                 ` Jason Gunthorpe
2025-07-10  9:04                                   ` Pranjal Shrivastava
2025-06-26 19:34 ` [PATCH v7 28/28] iommu/tegra241-cmdqv: Add IOMMU_VEVENTQ_TYPE_TEGRA241_CMDQV support Nicolin Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aGSNmf5Q82xEbDpX@google.com \
    --to=praan@google.com \
    --cc=alok.a.tiwari@oracle.com \
    --cc=bagasdotme@gmail.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=jonathanh@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=jsnitsel@redhat.com \
    --cc=kevin.tian@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mochs@nvidia.com \
    --cc=mshavit@google.com \
    --cc=nathan@kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=patches@lists.linux.dev \
    --cc=peterz@infradead.org \
    --cc=robin.murphy@arm.com \
    --cc=shuah@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=vasant.hegde@amd.com \
    --cc=vdumpa@nvidia.com \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.com \
    --cc=zhangzekun11@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.