Page MenuHomeFreeBSD

Update mips busdma to handle unmapped/out-of-context buffers
Needs ReviewPublic

Authored by jah on Oct 22 2015, 9:13 PM.



Use pmap_quick* functions in mips busdma, for bounce buffers and cache maintenance. This makes it safe to sync buffers that have no VA mapping associated with the busdma map, but may have other mappings, possibly on different CPUs. This also makes it safe to sync unmapped bounce buffers in non-sleepable thread contexts.

Similar to r286787 for x86, this treats userspace buffers the same as unmapped buffers and no longer borrows the UVA for sync operations.

While here, stop trying to use uncacheable memory for bounce buffers. It seems likely that the slowness of uncached copies would overwhelm the extra overhead of cache maintenance on the bounce buffers. If uncached memory does end up being needed here for some reason, kmem_alloc_contig(...VM_MEMATTR_UNCACHEABLE) should be used instead.

Diff Detail

rS FreeBSD src repository - subversion
Lint OK
No Unit Test Coverage
Build Status
Buildable 906
Build 906: arc lint + arc unit

Event Timeline

jah retitled this revision from to Update mips busdma to handle unmapped/out-of-context buffers.
jah updated this object.
jah edited the test plan for this revision. (Show Details)

Remove unclear comments on PHYS_TO_VM_PAGE().
Noted by: avg

In D3986#83554, @adrian wrote:

Can you test this out via a qemu-system-mips (from qemu-devel) package?

I have a stock MALTA64 (big endian) kernel booting under qemu...disk I/O seems to work fine. I'm building a mips32 image now.
Are there any workloads I should throw at it?

Just build some software or something that'll churn the VM and do disk IO. :)

In D3986#83956, @adrian wrote:

Just build some software or something that'll churn the VM and do disk IO. :)

I ended up just putting both the mips64 and mips32 VMs through buildworld. Everything seems to be fine.

ok, I'll try this out on some mips32 hardware and see what happens.

Does unmapped IO work with USB storage?