public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>,
	"Liu, Yi L" <yi.l.liu@intel.com>,
	"Tian, Kevin" <kevin.tian@intel.com>
Cc: "joro@8bytes.org" <joro@8bytes.org>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>,
	"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
	"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
	"yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
	"peterx@redhat.com" <peterx@redhat.com>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	"shameerali.kolothum.thodi@huawei.com" 
	<shameerali.kolothum.thodi@huawei.com>,
	"lulu@redhat.com" <lulu@redhat.com>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"Duan, Zhenzhong" <zhenzhong.duan@intel.com>
Subject: Re: [PATCH v4 09/12] iommu/vt-d: Add iotlb flush for nested domain
Date: Mon, 14 Aug 2023 23:18:46 -0700	[thread overview]
Message-ID: <ZNsYxta9Pi7USDoR@Asurada-Nvidia> (raw)
In-Reply-To: <ZNZlnh+/Q5Vk5Kul@Asurada-Nvidia>

On Fri, Aug 11, 2023 at 09:45:21AM -0700, Nicolin Chen wrote:

> > But if stepping back a bit supporting an array-based non-native format
> > could simplify the uAPI design and allows code sharing for array among
> > vendor drivers. You can still keep the entry as native format then the
> > only difference with future in-kernel fast path is just on walking an array
> > vs. walking a ring. And VMM doesn't need to expose non-invalidate
> > cmds to the kernel and then be skipped.
> 
> Ah, so we might still design the uAPI to be ring based at this
> moment, yet don't support a case CONS > 0 to leave that to an
> upgrade in the future.
> 
> I will try estimating a bit how complicated to implement the
> ring, to see if we could just start with that. Otherwise, will
> just start with an array.

I drafted a uAPI structure for a ring-based SW queue. While I am
trying an implementation, I'd like to collect some comments at the
structure, to see if it overall makes sense.

One thing that I couldn't add to this common structure for SMMU
is the hardware error code, which should be encoded in the higher
bits of the consumer index register, following the SMMU spec:
    ERR, bits [30:24] Error reason code.
    - When a command execution error is detected, ERR is set to a
      reason code and then the SMMU_GERROR.CMDQ_ERR global error
      becomes active.
    - The value in this field is UNKNOWN when the CMDQ_ERR global
      error is not active. This field resets to an UNKNOWN value.

But, I feel it odd to do the same to the generic structure. So,
perhaps an optional @out_error can be added to this structure. Or
some other idea?

Thanks
Nic

/**
 * struct iommu_hwpt_invalidate - ioctl(IOMMU_HWPT_INVALIDATE)
 * @size: sizeof(struct iommu_hwpt_invalidate)
 * @hwpt_id: HWPT ID of target hardware page table for the invalidation
 * @q_uptr: User pointer to an invalidation queue, which can be used as a flat
 *          array or a circular ring queue. The entiry(s) in the queue must be
 *          at a fixed width @q_entry_len, containing a user data structure for
 *          an invalidation request, specific to the given hardware pagetable.
 * @q_cons_uptr: User pointer to the consumer index (with its wrap flag) of an
 *               invalidation queue. This pointer must point to a __u32 type of
 *               memory location. The consumer index tells kernel to read from
 *               the entry pointed by it (and then its next entry) until kernel
 *               reaches the entry pointed by the producer index @q_prod, and
 *               allows kernel to update the consumer index to where it stops:
 *               on success, it should be updated to @q_prod; otherwise, to the
 *               index pointing to the failed entry.
 * @q_prod: Producer index (with its wrap flag) of an invalidation queue. This
 *          index points to the entry next to the last requested entry in the
 *          invalidation queue. In case of using the queue as a flat array, it
 *          equals to the number of entries @q_entry_num.
 * @q_index_bits: Effective bits of both indexes. Defines the maximum value an
 *                index can be. Must not be greater than 31 bits. A wrap flag
 *                is defined at the next higher bit adjacent to the index bits:
 *                e.g. if @q_index_bits is 20, @q_prod[19:0] are the index bits
 *                and @q_prod[20] is the wrap flag. The wrap flag, acting like
 *                a sign flag, must be toggled each time an index overflow and
 *                wraps to the lower end of the circular queue.
 * @q_entry_num: Totaly number of the entries in an invalidation queue
 * @q_entry_len: Length (in bytes) of an entry of an invalidation queue
 *
 * Invalidate the iommu cache for user-managed page table. Modifications on a
 * user-managed page table should be followed by this operation to sync cache.
 *
 * One request supports multiple invalidations via a multi-entry queue:
 *   |<----------- Length of Queue = @q_entry_num * @q_entry_len ------------>|
 *   --------------------------------------------------------------------------
 *   | 0 | 1 | 2 | 3 | ... | @q_entry_num-3 | @q_entry_num-2 | @q_entry_num-1 |
 *   --------------------------------------------------------------------------
 *   ^           ^                          ^                |<-@q_entry_len->|
 *   |           |                          |
 * @q_uptr  @q_cons_uptr                 @q_prod
 *
 * A queue index can wrap its index bits off the high end of the queue and back
 * onto the low end by toggling its wrap flag: e.g. when @q_entry_num=0x10 and
 * @q_index_bits=4, *@q_cons_uptr=0xf and @q_prod=0x11 inputs mean the producer
 * index is wrapped to 0x1 with its wrap flag set, so kernel reads/handles the
 * entry starting from by the consumer index (0xf) and wraps it back to 0x0 and
 * 0x1 by toggling the wrap flag, i.e. *@q_cons_uptr has a final value of 0x11.
 */
struct iommu_hwpt_invalidate {
	__u32 size;
	__u32 hwpt_id;
	__aligned_u64 q_uptr;
	__aligned_u64 q_cons_uptr;
	__u32 q_prod;
	__u32 q_index_bits;
	__u32 q_entry_num;
	__u32 q_entry_len;
};
#define IOMMU_HWPT_INVALIDATE _IO(IOMMUFD_TYPE, IOMMUFD_CMD_HWPT_INVALIDATE)

  reply	other threads:[~2023-08-15  6:22 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-24 11:13 [PATCH v4 00/12] Add Intel VT-d nested translation Yi Liu
2023-07-24 11:13 ` [PATCH v4 01/12] iommufd: Add data structure for Intel VT-d stage-1 domain allocation Yi Liu
2023-08-02  6:40   ` Tian, Kevin
2023-07-24 11:13 ` [PATCH v4 02/12] iommu/vt-d: Extend dmar_domain to support nested domain Yi Liu
2023-08-02  6:42   ` Tian, Kevin
2023-07-24 11:13 ` [PATCH v4 03/12] iommu/vt-d: Add helper for nested domain allocation Yi Liu
2023-08-02  6:44   ` Tian, Kevin
2023-07-24 11:13 ` [PATCH v4 04/12] iommu/vt-d: Add helper to setup pasid nested translation Yi Liu
2023-08-02  7:10   ` Tian, Kevin
2023-08-02  8:09     ` Baolu Lu
2023-08-02  8:11       ` Baolu Lu
2023-08-02  8:13         ` Tian, Kevin
2023-08-03  3:13     ` Baolu Lu
2023-08-03  3:58       ` Tian, Kevin
2023-07-24 11:13 ` [PATCH v4 05/12] iommu/vt-d: Make domain attach helpers to be extern Yi Liu
2023-08-02  7:14   ` Tian, Kevin
2023-07-24 11:13 ` [PATCH v4 06/12] iommu/vt-d: Set the nested domain to a device Yi Liu
2023-08-02  7:22   ` Tian, Kevin
2023-08-03  3:17     ` Baolu Lu
2023-07-24 11:13 ` [PATCH v4 07/12] iommufd: Add data structure for Intel VT-d stage-1 cache invalidation Yi Liu
2023-08-02  7:41   ` Tian, Kevin
2023-08-02 13:47     ` Jason Gunthorpe
2023-08-03  0:38       ` Tian, Kevin
2023-08-04 13:04         ` Liu, Yi L
2023-08-04 14:03           ` Jason Gunthorpe
2023-08-07 14:02             ` Liu, Yi L
2023-07-24 11:13 ` [PATCH v4 08/12] iommu/vt-d: Make iotlb flush helpers to be extern Yi Liu
2023-08-02  7:41   ` Tian, Kevin
2023-07-24 11:13 ` [PATCH v4 09/12] iommu/vt-d: Add iotlb flush for nested domain Yi Liu
2023-08-02  7:46   ` Tian, Kevin
2023-08-03  3:24     ` Baolu Lu
2023-08-03  4:00       ` Tian, Kevin
2023-08-03  4:05         ` Baolu Lu
2023-08-03  4:13           ` Tian, Kevin
2023-08-03  7:36             ` Baolu Lu
2023-08-07 15:08     ` Liu, Yi L
2023-08-08  3:12       ` Nicolin Chen
2023-08-08 12:34         ` Jason Gunthorpe
2023-08-08 17:41           ` Nicolin Chen
2023-08-09  8:22             ` Tian, Kevin
2023-08-09  8:50               ` Liu, Yi L
2023-08-09  8:58                 ` Tian, Kevin
2023-08-09  9:30                   ` Liu, Yi L
2023-08-09 16:24                     ` Jason Gunthorpe
2023-08-09 19:12                       ` Nicolin Chen
2023-08-09 19:19                         ` Jason Gunthorpe
2023-08-09 20:17                           ` Nicolin Chen
2023-08-10  2:49                             ` Tian, Kevin
2023-08-10 15:57                               ` Jason Gunthorpe
2023-08-10 17:14                                 ` Nicolin Chen
2023-08-10 19:27                                   ` Jason Gunthorpe
2023-08-10 21:02                                     ` Nicolin Chen
2023-08-11  3:52                                       ` Tian, Kevin
2023-08-11 16:45                                         ` Nicolin Chen
2023-08-15  6:18                                           ` Nicolin Chen [this message]
2023-08-18 16:56                                             ` Jason Gunthorpe
2023-08-18 17:56                                               ` Nicolin Chen
2023-08-18 18:20                                                 ` Jason Gunthorpe
2023-08-18 18:25                                                   ` Nicolin Chen
2023-08-21  1:24                                                     ` Tian, Kevin
2023-08-10  3:28                             ` Liu, Yi L
2023-08-10  3:33                               ` Nicolin Chen
2023-07-24 11:13 ` [PATCH v4 10/12] iommu/vt-d: Add nested domain allocation Yi Liu
2023-08-02  7:47   ` Tian, Kevin
2023-07-24 11:13 ` [PATCH v4 11/12] iommu/vt-d: Implement hw_info for iommu capability query Yi Liu
2023-08-15 16:31   ` Jason Gunthorpe
2023-08-16  0:35     ` Baolu Lu
2023-08-16  1:10       ` Nicolin Chen
2023-08-16 11:46       ` Jason Gunthorpe
2023-08-16 11:48         ` Baolu Lu
2023-08-16 12:03           ` Liu, Yi L
2023-07-24 11:13 ` [PATCH v4 12/12] iommu/vt-d: Disallow nesting on domains with read-only mappings Yi Liu
2023-08-02  7:59   ` Tian, Kevin
2023-08-03  3:27     ` Baolu Lu
2023-08-03  4:00       ` Tian, Kevin

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=ZNsYxta9Pi7USDoR@Asurada-Nvidia \
    --to=nicolinc@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=cohuck@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux.dev \
    --cc=jasowang@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=mjrosato@linux.ibm.com \
    --cc=peterx@redhat.com \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=yi.l.liu@intel.com \
    --cc=yi.y.sun@linux.intel.com \
    --cc=zhenzhong.duan@intel.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