Date: Wed, 29 Apr 2015 14:17:50 -0500 From: Jason Harmening <jason.harmening@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Svatopluk Kraus <onwahe@gmail.com>, John Baldwin <jhb@freebsd.org>, Adrian Chadd <adrian@freebsd.org>, Warner Losh <imp@bsdimp.com>, freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space Message-ID: <CAM=8qanPHbCwUeu0-zi-ccY4WprHaOGzCm44PwNSgb==nwgGGw@mail.gmail.com> In-Reply-To: <20150429185019.GO2390@kib.kiev.ua> References: <CAFHCsPXMjge84AR2cR8KXMXWP4kH2YvuV_uqtPKUvn5C3ygknw@mail.gmail.com> <38574E63-2D74-4ECB-8D68-09AC76DFB30C@bsdimp.com> <CAJ-VmomqGkEFVauya%2BrmPGcD_-=Z-mmg1RSDf1D2bT_DfwPBGA@mail.gmail.com> <1761247.Bq816CMB8v@ralph.baldwin.cx> <CAFHCsPX9rgmCAPABct84a000NuBPQm5sprOAQr9BTT6Ev6KZcQ@mail.gmail.com> <20150429132017.GM2390@kib.kiev.ua> <CAFHCsPWjEFBF%2B-7SR7EJ3UHP6oAAa9xjbu0CbRaQvd_-6gKuAQ@mail.gmail.com> <20150429165432.GN2390@kib.kiev.ua> <CAM=8qakzkKX8TZNYE33H=JqL_r5z%2BAU9fyp5%2B7Z0mixmF5t63w@mail.gmail.com> <20150429185019.GO2390@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM=8qanPHbCwUeu0-zi-ccY4WprHaOGzCm44PwNSgb==nwgGGw>