Page MenuHomeFreeBSD

Update powerpc busdma to handle unmapped/out-of-context buffers
ClosedPublic

Authored by jah on Oct 22 2015, 10:02 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Dec 14, 2:39 AM
Unknown Object (File)
Sat, Nov 30, 11:58 AM
Unknown Object (File)
Oct 4 2024, 7:42 AM
Unknown Object (File)
Sep 20 2024, 1:45 AM
Unknown Object (File)
Sep 18 2024, 12:09 PM
Unknown Object (File)
Sep 18 2024, 12:09 PM
Unknown Object (File)
Sep 18 2024, 12:09 PM
Unknown Object (File)
Sep 18 2024, 12:09 PM
Subscribers

Details

Summary

Use pmap_quick* to handle bouncing of unmapped buffers. Also treat usermode buffers as unmapped, to avoid borrowing the UVA for copies. This allows sync'ing usermode buffers outside the context of the owning process, and sync'ing bounced maps in non-sleepable contexts.

This is equivalent to r286787 for x86.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 907
Build 907: arc lint + arc unit

Event Timeline

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

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

Code looks fine. I won't have time to test for a while, so want a second opinion.

This one's been sitting for a while. Anything I can do to test this out on my own? qemu maybe?

I think qemu can boot powerpc64 (see https://wiki.freebsd.org/QemuRecipes ). What kinds of testing should be done? I have a Book-E board I could boot test with, and do basic SATA I/O, would that be enough? I also have some PowerMac hardware. Would need a week or two before I can test with that though.

I think qemu can boot powerpc64 (see https://wiki.freebsd.org/QemuRecipes ). What kinds of testing should be done? I have a Book-E board I could boot test with, and do basic SATA I/O, would that be enough? I also have some PowerMac hardware. Would need a week or two before I can test with that though.

A week or two is no problem.
The busdma logic here is basically the same as x86, so the big risk is that I got something wrong in the powerpc implementation of pmap_quick_enter_page. Would SATA or network I/O end up bouncing on either qemu or your hardware?

A week or two is no problem.
The busdma logic here is basically the same as x86, so the big risk is that I got something wrong in the powerpc implementation of pmap_quick_enter_page. Would SATA or network I/O end up bouncing on either qemu or your hardware?

Reading the busdma_machdep source, it looks as though it'll bounce if the lowaddr of the created tag, or an alignment > 1, so probably similar to how x86 bounces. It looks like I can test on my book-e hardware, which uses my new fsl_sata driver (lowaddr of BUS_SPACE_MAXADDR_32BIT, on a machine with 6GB RAM). Network traffic might do it on qemu as well.

jhibbits edited edge metadata.

Did some light testing, but not sure if I triggered anything.

This revision is now accepted and ready to land.Jul 24 2016, 12:52 AM

Did some light testing, but not sure if I triggered anything.

Thanks for testing it!
I also have a simple kmod at https://reviews.freebsd.org/D3014 just for testing pmap_quick_enter_page(). The difference between x86 and ppc implementations of that function is the real risk in this change, since the busdma code is basically the same as x86 (or at least as x86 used to be before some recent xen-related changes).

I haven't had any luck w/ ppc64 on qemu yet. 11.0-beta2 iso hangs while loading the kernel. I've also tried to create a custom disk image the way I do for mips (https://wiki.freebsd.org/FreeBSD/MipsEmulation) but that gets me a weird-looking exception from OFW when it tries to load the kernel.

This revision was automatically updated to reflect the committed changes.