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.
Thanks,
Sumit
>
> Thanks,
>
> Bart.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
