physio and vmapbuf

[Kostik Belousov]

On Wed, Mar 10, 2010 at 01:40:18PM +0200, son goku wrote:
> Hi hackers,
> I have some experience with other UNIX kernels but none with FreeBSD.
> FreeBSD interests me for a potential project I might be involved in , and
> therefore I started researching it.
> Browsing through the I/O layer code, I stumbled upon something that looked
> strange, and perhaps you guys can help me with it.
> Mainly, when reading the physio path, when the I/O buffer is from user-mode,
> physio calls vmapbuf. The comments says that vmapbuf actually maps the
> user-buffer into kernel address space. From my experience, such mapping is
> needed only for very old devices that use PIO. Newer device just use DMA for
> data copy, and therefore don't need the mapping, instead they just need to
> pin the memory. Checking out vmapbuf only confused me further, I couldn't
> find where such kernel mapping was taken place, nevertheless I did saw that
> the buf->b_data was updated according to buf->b_saveaddr in some weird
> offset calculation.
> Adding to this confusion, there is a buf field called b_kvabase which
> supposedly stores the kernel virtual address which wasn't touched at all!!
> 
> Any help with understanding the flow and the usage of those fields/variables
> will be greatly appreciated!!

For normal VMIO buffers, b_kvabase is provided on the buffer
initialization, see getnewbuf() and allocbuf(). b_saveaddr is
initialized equial to b_kvabase.

But note that physio uses pbufs, that are essentially buffer header
and some reserved kva space. Note the
	bp = getpbuf(NULL);
	sa = bp->b_data;
at the start of physio(), and then
			bp->b_saveaddr = sa;
later at the buffer set up.

vmapbuf() looks up the pages using vm_fault_quick()/pmap_extract_and_hold()
loop, and then maps the pages into pbuf kva by pmap_qenter().
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20100310/d325c1f2/attachment.pgp