From owner-freebsd-arm@FreeBSD.ORG Tue Aug 28 13:48:53 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CCE4106566C; Tue, 28 Aug 2012 13:48:53 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id DDDF58FC17; Tue, 28 Aug 2012 13:48:51 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so9660554pbb.13 for ; Tue, 28 Aug 2012 06:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P71mtBUeKJqJJ7uppZZUYzebtvvWMylC3ZFDuLWwN8U=; b=bHZLuzFKqvhefHZ1LPS5tIpUsqC75R1yub1u8o2tFUZoD5ipMaiREpoTrKdMT7Emxe dnj+MRbW+060ycWl/z6nYyRNRPZTFa448jZz9i2j6C9d9ucVZAoRZeVWkxflBRdoLPMg +/SnpzKDAqAgwiHQJwZoTo4N0mHy64YtmDaxMpnKRl0TJxFZovCxGuVOnie5nHCH/rE9 OneNADf1F1c1eEp3mNDK/8FrZeRFWghdsCcbVk747yOV5YDPmORpnyqMNlfCbVgNqcJF gDNyB6UKcpKjaNyb/zQeH/WsKEDkXVME05CdzU/QWMEhNo7GT3GF2v/ITheHdTzvYmRc C6yQ== MIME-Version: 1.0 Received: by 10.68.231.130 with SMTP id tg2mr3863853pbc.70.1346161731445; Tue, 28 Aug 2012 06:48:51 -0700 (PDT) Received: by 10.68.229.227 with HTTP; Tue, 28 Aug 2012 06:48:51 -0700 (PDT) In-Reply-To: <201208271531.42725.jhb@freebsd.org> References: <10307B47-13F3-45C0-87F7-66FD3ACA3F86@bsdimp.com> <20120827185346.GE33100@deviant.kiev.zoral.com.ua> <201208271531.42725.jhb@freebsd.org> Date: Tue, 28 Aug 2012 08:48:51 -0500 Message-ID: From: Mark Tinguely To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Hans Petter Selasky , freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org, Konstantin Belousov Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 13:48:53 -0000 On Mon, Aug 27, 2012 at 2:31 PM, John Baldwin wrote: > On Monday, August 27, 2012 2:53:46 pm Konstantin Belousov wrote: >> On Sun, Aug 26, 2012 at 05:13:31PM -0600, Warner Losh wrote: >> > >> > 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. >> > >> > 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 ? > > No. The caller is required to wire the pages first in some manner. > In general bus_dmamap_load_uio() isn't a good idea. I do believe the > crypto drivers are careful to wire the buffer first. I think requiring > the caller to wire is the only sane way that can be used. > > Also, doing DMA to a stack variable is absolutely horrible for a related > reason since presumably the thread will block while it waits for the DMA > to complete, and a sleeping thread can be swapped out (including having > it's stack swapped out). > > -- > John Baldwin The POST commands for UIO DMA may be a bit hairy because the address space may not be the same as the caller. Someone once told me they got around that (in a Sparc enviroment?) by shadow mapping the address to KVA. --Mark TInguely.