bus_dmamap_sync() for bounced client buffers from user address space

[Jason Harmening]

>
>
> The spaces/tabs in your mail are damaged. It does not matter in the
> text, but makes the patch unapplicable and hardly readable.
>

Ugh.  I'm at work right now and using the gmail web client.  It seems like
every day I find a new way in which that thing is incredibly unfriendly for
use with mailing lists.
I will re-post the patch from a sane mail client later.


>
> I only read the x86/busdma_bounce.c part.  It looks fine in the part
> where you add the test for the current pmap being identical to the pmap
> owning the user page mapping.
>
> I do not understand the part of the diff for bcopy/physcopyout lines,
> I cannot find non-whitespace changes there, and whitespace change would
> make too long line.  Did I misread the patch ?\
>

You probably misread it, since it is unreadable.  There is a section in
bounce_bus_dmamap_sync() where I check for map->pmap being kernel_pmap or
curproc's pmap before doing bcopy.


>
> BTW, why not use physcopyout() unconditionally on x86 ? To avoid i386 sfbuf
> allocation failures ?
>

Yes.


>
> For non-coherent arches, isn't the issue of CPUs having filled caches
> for the DMA region present regardless of the vm_fault_quick_hold() use ?
> DMASYNC_PREREAD/WRITE must ensure that the lines are written back and
> invalidated even now, or always fall back to use bounce page.
>
>
Yes, that needs to be done regardless of how the pages are wired.  The
particular problem here is that some caches on arm and mips are
virtually-indexed (usually virtually-indexed, physically-tagged (VIPT)).
That means the flush/invalidate instructions need virtual addresses, so
figuring out the correct UVA to use for those could be a challenge.  As I
understand it, VIPT caches usually do have some hardware logic for finding
all the cachelines that correspond to a physical address, so they can
handle multiple VA mappings of the same PA.  But it is unclear to me how
cross-processor cache maintenance is supposed to work with VIPT caches on
SMP systems.

If the caches were physically-indexed, then I don't think there would be an
issue.  You'd just pass the PA to the flush/invalidate instruction, and
presumably a sane SMP implementation would propagate that to other cores
via IPI.