Query regarding Unmapped IO, PIM_UNMAPPED and bus_dmamap_load_ccb()

[Konstantin Belousov]

On Mon, Nov 10, 2014 at 03:43:44PM +0530, Sibananda Sahu wrote:
> Hi Konstantin,
> 
> +++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.
> 
> Thanks for this information.
> I have checked the header for the above mentioned data and understood how
> it happens.
> 
> Further I have observed that the CAM_DATA_BIO is the case when I am
> reading some data out of the disk.
> But when I am writing some data to the disk I am getting the request via
> CAM_DATA_VADDR.
> Is the BIO meant only for READs???

BIOs are used both for reads and writes.  Your VADDR request is some BIO
as well, it was just 'disassembled' into the buffer request by some upper
layer before reaching the driver.

Your observation that you only get unmapped reads is due to your testing
load, and is not something that system enforces.  Both reads and writes
may happen mapped or unmapped, driver cannot rely on absence of any
specific requests.  Test UFS-formatted volume on the disk handled by
the driver, it will give you ample amount of unmapped reads and writes.