Date: Mon, 27 Aug 2012 21:53:46 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Hans Petter Selasky <hans.petter.selasky@bitfrost.no>, freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS Message-ID: <20120827185346.GE33100@deviant.kiev.zoral.com.ua> In-Reply-To: <10307B47-13F3-45C0-87F7-66FD3ACA3F86@bsdimp.com> References: <FD8DC82C-AD3B-4EBC-A625-62A37B9ECBF1@bsdimp.com> <1345765503.27688.602.camel@revolution.hippie.lan> <CAJ-VmonOwgR7TNuYGtTOhAbgz-opti_MRJgc8G%2BB9xB3NvPFJQ@mail.gmail.com> <1345766109.27688.606.camel@revolution.hippie.lan> <CAJ-VmomFhqV5rTDf-kKQfbSuW7SSiSnqPEjGPtxWjaHFA046kQ@mail.gmail.com> <F8C9E811-8597-4ED0-9F9D-786EB2301D6F@bsdimp.com> <1346002922.1140.56.camel@revolution.hippie.lan> <CAP%2BM-_HZ4yARwZA2koPJDeJWHT-1LORupjymuVnMtLBzeXe=DA@mail.gmail.com> <1346005507.1140.69.camel@revolution.hippie.lan> <10307B47-13F3-45C0-87F7-66FD3ACA3F86@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--BwgxZU5iS1dWSTZh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 26, 2012 at 05:13:31PM -0600, Warner Losh wrote: >=20 > On Aug 26, 2012, at 12:25 PM, Ian Lepore wrote: > > In this regard, it's the busdma implementation that's broken, because it > > should bounce those IOs through a DMA-safe buffer. There's absolutely > > no rule that I've ever heard of in FreeBSD that says IO can only take > > place using memory allocated from busdma. >=20 > That's partially true. Since BUSDMA grew up in the storage area, you > must allocate the memory from busdma, or it must be page aligned has > been the de-facto rule here. The mbuf and uio variants of load were > invented to cope with common cases of mbufs and user I/O to properly > flag things. I once looked at x86 bus_dmamap_load_uio(), and I was unable to understand how to use it with usermode uio. I think this is a good moment to ask. Most existing users use UIO_SYSSPACE, but several crypto drivers might allow the UIO_USERSPACE for them. For UIO_USERSPACE, if the page is not resident, the pmap_extract() call from _bus_dmamap_load_buffer() returns 0. So the i/o happens to the page located at 0, which contains real mode IVT and other BIOS sensitive tables. Worse, if the page is resident, but it is mapped at the region which requires COW on write, then DMA will be performed to the wrong page which is typically shared with other innocent users. to the COW area which was not yet copied, Am I missing some trick there ? --BwgxZU5iS1dWSTZh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlA7wjoACgkQC3+MBN1Mb4hJsACg9rY5d4jEjVBz1gmM0pcHvbwY 1N0AoKmBOQ6HFrErCDyO1ME2rbSRZLt/ =iNrn -----END PGP SIGNATURE----- --BwgxZU5iS1dWSTZh--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120827185346.GE33100>