Date: Wed, 29 Apr 2015 22:33:37 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Jason Harmening <jason.harmening@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: <20150429193337.GQ2390@kib.kiev.ua> In-Reply-To: <CAM=8qanPHbCwUeu0-zi-ccY4WprHaOGzCm44PwNSgb==nwgGGw@mail.gmail.com> References: <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> <CAM=8qanPHbCwUeu0-zi-ccY4WprHaOGzCm44PwNSgb==nwgGGw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 29, 2015 at 02:17:50PM -0500, Jason Harmening wrote: > > > > > > 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. See the paragraph in my mail before the one you answered. I am asking about the bcopy()/physcopyout() lines in diff, not about the if () conditions change. The later is definitely fine. > > > > > > 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. Even without SMP, VIPT cache cannot hold two mappings of the same page. As I understand, sometimes it is more involved, eg if mappings have correct color (eg. on ultrasparcs), then cache can deal with aliasing. Otherwise pmap has to map the page uncached for all mappings. I do not see what would make this case special for SMP after that. Cache invalidation would be either not needed, or coherency domain propagation of the virtual address does the right thing.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150429193337.GQ2390>