On 4/4/22 08:07, Sumit Saxena wrote:
On Mon, Apr 4, 2022 at 7:55 PM Bart Van Assche <bvanassche@xxxxxxx> wrote:
On 3/29/22 11:06, Sumit Saxena wrote:
+/**
+ * struct mpi3mr_nvme_pt_sge - Structure to store SGEs for NVMe
+ * Encapsulated commands.
+ *
+ * @base_addr: Physical address
+ * @length: SGE length
+ * @rsvd: Reserved
+ * @rsvd1: Reserved
+ * @sgl_type: sgl type
+ */
+struct mpi3mr_nvme_pt_sge {
+ u64 base_addr;
+ u32 length;
+ u16 rsvd;
+ u8 rsvd1;
+ u8 sgl_type;
+};
Does the above data structure force user space software to pass a
physical address to the kernel? A kernel driver should not do this
unless there is a very good reason to do so. Passing a physical address
from user space to the kernel requires freezing the virtual-to-physical
mapping. Some user space developers erroneously use mlock() for this
purpose. Is there any other way than the VFIO_IOMMU_MAP_DMA ioctl to
prevent that the kernel modifies the virtual-to-physical mapping?
>
This structure is not for user space consumption. Mistakenly, it's moved
to this header. Will fix it in the next revision.
I can't find any code in the kernel that stores the value
MPI3_FUNCTION_NVME_ENCAPSULATED. Does that mean that that value is set
by user space and hence that the definition of that constant should
occur in a uapi header? Same question for struct
mpi3_nvme_encapsulated_request.
Thanks,
Bart.
