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: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