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)
next prev parent reply other threads:[~2023-08-15 6:19 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 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.