public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: Vasant Hegde <vasant.hegde@amd.com>
Cc: Jason Gunthorpe <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>, <praan@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>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Subject: Re: [PATCH v3 11/23] iommufd/viommu: Add IOMMUFD_CMD_VQUEUE_ALLOC ioctl
Date: Wed, 7 May 2025 22:56:17 -0700	[thread overview]
Message-ID: <aBxHgf4llBd7vA5w@nvidia.com> (raw)
In-Reply-To: <2356ff85-6651-47d9-90c7-f8cbf43b053b@amd.com>

On Thu, May 08, 2025 at 10:16:51AM +0530, Vasant Hegde wrote:
> >>   - There is other bit "Completion wait interrupt enable"
> >>     This doesn't related to any buffer. Instead if we configure this for
> >> completion wait command it will generate interrupt.
> > 
> > This sounds like a modify on the VIOMMU object?
> 
> Again in my view its VIOMMU object as it tells HW what to do when it finishes
> completion wait command.

According to the spec:
https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/specifications/48882_IOMMU.pdf

This is for an interrupt from a COMPLETION_WAIT command:
"The COMPLETION_WAIT command allows software to serialize itself
 with IOMMU command processing. The COMPLETION_WAIT command does
 not finish until all older commands issued since a prior
 COMPLETION_WAIT have completely executed."

So, basically it's like the IRQ for CMD_SYNC on ARM. IMHO, this is
very specific to Command Buffer (i.e. a vQUEUE object, and now HW
QUEUE object), though the bit is located in a global IOMMU control
register.

Looking at this paragraph:
"
To restart the IOMMU command processing after the IOMMU halts it,
use the following procedure.
• Wait until CmdBufRun=0b in the IOMMU Status Register
   [MMIO Offset 2020h] so that all commands complete processing as
   the circumstances allow. CmdBufRun must be 0b to modify the
   command buffer registers properly.
• Set CmdBufEn=0b in the IOMMU Control Register [MMIO Offset 0018h].
• As necessary, change the following registers (e.g., to relocate
   the command buffer):
   • the Command Buffer Base Address Register [MMIO Offset 0008h],
   • the Command Buffer Head Pointer Register [MMIO Offset 2000h],
   • the Command Buffer Tail Pointer Register [MMIO Offset 2008h].
• Any or all command buffer entries may be copied from the old
   command buffer to the new and software must set the head and tail
   pointers appropriately.
• Write the IOMMU Control Register [MMIO Offset 0018h] with
   CmdBufEn=1b and ComWaitIntEn as desired
",
the ComWaitIntEn bit is suggested to be set along with the CmdBufEn
bit, i.e. it can be a part of the IOMMU_HW_QUEUE_ALLOC ioctl.

What I am not sure is if the HW allows setting the ComWaitIntEn bit
after CmdBufEn=1, which seems to be unlikely but the spec does not
highlight. If so, this would be an modification to the HW QUEUE, in
which case we could either do an relocation of the HW QUEUE (where
we can set the flag in the 2nd allocation) or add an new option via
IOMMUFD_CMD_OPTION (as Kevin suggested), and I think it should be
a per-HW_QUEUE option since it doesn't affect other type of queues
like Event/PRR Log Buffers.

Similarly, an Event Log Buffer can have an EventIntEn flag; and a
PPR Log Buffer can have an PprIntEn flag too, right?

Thanks
Nicolin

  reply	other threads:[~2025-05-08  5:56 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-01 23:01 [PATCH v3 00/23] iommufd: Add vIOMMU infrastructure (Part-4 vQUEUE) Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 01/23] iommufd/viommu: Add driver-allocated vDEVICE support Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 02/23] iommu: Pass in a driver-level user data structure to viommu_alloc op Nicolin Chen
2025-05-06  5:43   ` Vasant Hegde
2025-05-01 23:01 ` [PATCH v3 03/23] iommufd/viommu: Allow driver-specific user data for a vIOMMU object Nicolin Chen
2025-05-06  9:32   ` Vasant Hegde
2025-05-01 23:01 ` [PATCH v3 04/23] iommu: Add iommu_copy_struct_to_user helper Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 05/23] iommufd/driver: Let iommufd_viommu_alloc helper save ictx to viommu->ictx Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 06/23] iommufd/driver: Add iommufd_struct_destroy to revert iommufd_viommu_alloc Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 07/23] iommufd/selftest: Support user_data in mock_viommu_alloc Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 08/23] iommufd/selftest: Add covearge for viommu data Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 09/23] iommufd: Abstract iopt_pin_pages and iopt_unpin_pages helpers Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 10/23] iommufd/viommu: Introduce IOMMUFD_OBJ_VQUEUE and its related struct Nicolin Chen
2025-05-06  9:17   ` Vasant Hegde
2025-05-01 23:01 ` [PATCH v3 11/23] iommufd/viommu: Add IOMMUFD_CMD_VQUEUE_ALLOC ioctl Nicolin Chen
2025-05-06  9:15   ` Vasant Hegde
2025-05-06 12:01     ` Jason Gunthorpe
2025-05-07  7:41       ` Vasant Hegde
2025-05-07  8:00         ` Tian, Kevin
2025-05-07 12:31         ` Jason Gunthorpe
2025-05-08  4:46           ` Vasant Hegde
2025-05-08  5:56             ` Nicolin Chen [this message]
2025-05-08 12:14               ` Jason Gunthorpe
2025-05-08 17:12                 ` Nicolin Chen
2025-05-09 11:52                   ` Vasant Hegde
2025-05-01 23:01 ` [PATCH v3 12/23] iommufd/driver: Add iommufd_vqueue_depend/undepend() helpers Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 13/23] iommufd/selftest: Add coverage for IOMMUFD_CMD_VQUEUE_ALLOC Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 14/23] iommufd: Add mmap interface Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 15/23] iommufd/selftest: Add coverage for the new " Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 16/23] Documentation: userspace-api: iommufd: Update vQUEUE Nicolin Chen
2025-05-02  3:50   ` Bagas Sanjaya
2025-05-02  5:29     ` Nicolin Chen
2025-05-02  7:31       ` Bagas Sanjaya
2025-05-01 23:01 ` [PATCH v3 17/23] iommu/arm-smmu-v3-iommufd: Add vsmmu_alloc impl op Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 18/23] iommu/arm-smmu-v3-iommufd: Support implementation-defined hw_info Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 19/23] iommu/tegra241-cmdqv: Use request_threaded_irq Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 20/23] iommu/tegra241-cmdqv: Simplify deinit flow in tegra241_cmdqv_remove_vintf() Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 21/23] iommu/tegra241-cmdqv: Do not statically map LVCMDQs Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 22/23] iommu/tegra241-cmdqv: Add user-space use support Nicolin Chen
2025-05-01 23:09   ` Nicolin Chen
2025-05-01 23:01 ` [PATCH v3 23/23] 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=aBxHgf4llBd7vA5w@nvidia.com \
    --to=nicolinc@nvidia.com \
    --cc=alok.a.tiwari@oracle.com \
    --cc=bagasdotme@gmail.com \
    --cc=corbet@lwn.net \
    --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=patches@lists.linux.dev \
    --cc=peterz@infradead.org \
    --cc=praan@google.com \
    --cc=robin.murphy@arm.com \
    --cc=shuah@kernel.org \
    --cc=suravee.suthikulpanit@amd.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox