Re: scsipi: physio split the request

[Jason Thorpe <thorpej%me.com@localhost>]

> On Dec 27, 2018, at 10:51 AM, Michael van Elst <mlelstv%serpens.de@localhost> wrote:
> 
> manu%netbsd.org@localhost (Emmanuel Dreyfus) writes:
> 
>> What happens if I just #define MAXPHYS (1024*1204*1024) ?
> 
> You need a really huge amount of RAM for that, and also a huge
> KVA space.

...but it doesn't have to be that way.

The fundamental problem is that for physio, we currently have to map the buffer into kernel space at all.  We really should have a more abstract way to describe memory that is passed down to device drivers that currently take struct buf *s, call it an I/O memory descriptor ("iomd").  This iomd would have, say, an array of vm_page *'s, or perhaps an array of paddr_t's, but would also have a pointer to the buffer as mapped into kernel address space.  The necessary part is having the page array filled in, along with an offset, and a length.  If not sufficient, then callers could map the buffer ONLY if needed, e.g. if you have to do PIO to your device.

Then a new bus_dmamap_load_iomd() call could take an iomd as an argument, and skip doing a bunch of work (calling into the pmap later to get the physical address), and just build the bus_dma_segment_t's directly.  If it needs to bounce-buffer, then the back-end takes care of calling iomd_map() or whatever.

This isn't a fully fleshed-out proposal, or anything, but I know it's ben brought up off and on for years... we really ought to just get around to doing it.  Unfortunately, it's going to mean modifying a lot of drivers before the upper layers can assume "I can pass iomds down everywhere for buf I/O".

-- thorpej