[PATCH v4 15/16] block-dma: properly take MMIO path
Leon Romanovsky
leon at kernel.org
Fri Aug 29 02:54:27 AEST 2025
On Thu, Aug 28, 2025 at 09:19:20AM -0600, Keith Busch wrote:
> On Tue, Aug 19, 2025 at 08:36:59PM +0300, Leon Romanovsky wrote:
> > diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> > index 09b99d52fd36..283058bcb5b1 100644
> > --- a/include/linux/blk_types.h
> > +++ b/include/linux/blk_types.h
> > @@ -387,6 +387,7 @@ enum req_flag_bits {
> > __REQ_FS_PRIVATE, /* for file system (submitter) use */
> > __REQ_ATOMIC, /* for atomic write operations */
> > __REQ_P2PDMA, /* contains P2P DMA pages */
> > + __REQ_MMIO, /* contains MMIO memory */
> > /*
> > * Command specific flags, keep last:
> > */
> > @@ -420,6 +421,7 @@ enum req_flag_bits {
> > #define REQ_FS_PRIVATE (__force blk_opf_t)(1ULL << __REQ_FS_PRIVATE)
> > #define REQ_ATOMIC (__force blk_opf_t)(1ULL << __REQ_ATOMIC)
> > #define REQ_P2PDMA (__force blk_opf_t)(1ULL << __REQ_P2PDMA)
> > +#define REQ_MMIO (__force blk_opf_t)(1ULL << __REQ_MMIO)
>
> Now that my integrity metadata DMA series is staged, I don't think we
> can use REQ flags like this because data and metadata may have different
> mapping types. I think we should add a flags field to the dma_iova_state
> instead.
Before integrity metadata code was merged, the assumption was that request is
only one type or p2p or host. Is it still holding now?
And we can't store in dma_iova_state() as HMM/RDMA code works in page-based
granularity and one dma_iova_state() can mix different types.
Thanks
>
More information about the Linuxppc-dev
mailing list