> On Dec 27, 2018, at 10:51 AM, Michael van Elst <[email protected]> wrote:
>
> [email protected] (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
