Query regarding Unmapped IO, PIM_UNMAPPED and bus_dmamap_load_ccb()

[Konstantin Belousov]

On Fri, Nov 07, 2014 at 05:07:59AM +0530, Sibananda Sahu wrote:
> Hi All,
> 
> 
> 
> I have raised this query regarding the following mail:
> 
> https://lists.freebsd.org/pipermail/freebsd-scsi/2014-July/006407.html
> 
> 
> 
> Where Alexander Motin talks of Unmapped I/O.
> 
> As per his direction I have declared the below statement in my driver code:
> 
> 
> 
> ccb->cpi.hba_misc = PIM_NOBUSRESET | PIM_UNMAPPED;
> 
> 
> 
> Before enabling PIM_UNMAPPED I was getting the (ccb->ccb_h.flags &
> CAM_DATA_MASK) as CAM_DATA_VADDR and handling accordingly.
> 
> But after enabling PIM_UNMAPPED in cpi.hba_misc I am getting the
> (ccb->ccb_h.flags & CAM_DATA_MASK) as CAM_DATA_BIO and handling the data
> that comes with bus_dma_load_ccb().
Right.

Look at the code.  In particular, the definition of the struct bio
in sys/sys/bio.h.  There, the buffer pointed by bio_data is passed
if BIO_UNMAPPED flag is not set, but when the flag is set, bio_ma*
fields describe an array of physical memory pages where the data for
i/o request are scattered.  The pages are not neccessary mapped into
the KVA, which explains the terminology.

The i/o stack and busdma(9) where modified to transparently handle
such requests, and you correctly described the minimal changes,
required from the driver side to process the unmapped requests.
The passing of a pointer to bio instead of the pointer to buffer
allows drivers to not care about mapped/not mapped requests,
assuming the suitable KPI like bus_dma_load_ccb() prepares the
buffer for dma engine of the controller.

> 
> 
> 
> I just did the same thing according to the mps(4) driver as referred by
> Alexander Motin.
> 
> 
> 
> So I just wanted to know what exactly happening when I am enabling the
> PIM_UNMAPPED in the cpi.hba_misc field.
> 
> And what the CAM_DATA_BIO really means in the CAM_DATA_MASK.
> 
> 
> 
> 
> 
> It would be great idea if somebody explains what exactly happening or at
> least give me some references where can I have a look and move forward.
> 
> 
> 
> 
> 
> Thanks,
> 
> Sibananda Sahu
> _______________________________________________
> freebsd-scsi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe at freebsd.org"