From owner-freebsd-arch@freebsd.org Tue Jul 7 16:37:58 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B05D4996D9B for ; Tue, 7 Jul 2015 16:37:58 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5186716EF for ; Tue, 7 Jul 2015 16:37:58 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by lagc2 with SMTP id c2so200292609lag.3 for ; Tue, 07 Jul 2015 09:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bFkfkGuPOwzYuCuhtUxsKdoAZdOCmM6i1s8mj0qRr6Q=; b=OUrLB13+fPVYqLIi/ufxmzCEOhfHyZq3M1wEQT79L8Oz3w8wU9LRemWxwW+dIvRHkB 7wZNxx9UzhxnY8gpzL0nfKJQnkRXcN4d8nJWwW28KLWFtH6zH6lCdMn8r3USNkuRXsdY WF3Qr+p5Mu/14k1t8BIdEUqoXijTzFflozxgAgkN8u7F3/ym850lgdUsWg7rmhbCP0Ff +9fn+Q5LElU2jk1nlvbt+nSFf+40RUhbd0ntz60v06Er4Q49KW550aeSSjKAcKOiu3OC p9u7PkWKilLvBSitsEXq72JLlvZ4abzSmt9HnI31VQ9jN61xqMZTS4jD/tfrhWdaiqwH DP8w== MIME-Version: 1.0 X-Received: by 10.112.137.164 with SMTP id qj4mr4759695lbb.105.1436287076019; Tue, 07 Jul 2015 09:37:56 -0700 (PDT) Received: by 10.112.42.162 with HTTP; Tue, 7 Jul 2015 09:37:55 -0700 (PDT) Date: Tue, 7 Jul 2015 11:37:55 -0500 Message-ID: Subject: RFC: New KPI for fast temporary single-page KVA mappings From: Jason Harmening To: FreeBSD Arch Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 16:37:58 -0000 Hi everyone, I'd like to propose a couple of new pmap functions: vm_offset_t pmap_quick_enter_page(vm_page_t m) void pmap_quick_remove_page(vm_offset_t kva) These functions will create and destroy a temporary, usually CPU-local mapping of the specified page. Where available, they will use the direct map. Otherwise, they will use a per-CPU pageframe that's allocated at boot. Guarantees: --Will not sleep --Will not fail --Safe to call under a non-spin lock or from an ithread Restrictions: --Not safe to call from interrupt filter or under a spin mutex on all arches --Mappings should be held for as little time as possible; don't do any locking or sleeping while holding a mapping --Current implementation only guarantees a single page of mapping space across all arches. MI code should not make nested calls to pmap_quick_enter_page(). My idea is that the first consumer of this would be busdma. All non-iommu implementations would use this for bounce buffer copies of pages that don't have resident mappings. Currently busdma uses physcopy[in|out] for unmapped buffers, which on most arches uses sf_bufs that can sleep, making bus_dmamap_sync() unsafe to call in a lot of cases. busdma would also use this for virtually-indexed cache maintenance on arm and mips. It currently ignores cache maintenance for buffers that don't have a KVA or resident UVA mapping, which may not be correct for buffers that don't belong to curproc or have cache-resident VAs on other cores. I've created 2 Differential reviews: https://reviews.freebsd.org/D3013: the implementation https://reviews.freebsd.org/D3014: the kmod I've been using to test it I'd like any and all feedback, both on the general approach and the implementation details. Some things to note on the implementation: --I've intentionally avoided touching existing pmap code for the time being. Some of the new code could likely be shared with other pmap KPIs in a lot of cases. --I've structured the KPI to make it easy to extend to guarantee more than one per-CPU page in the future. I could see that being useful for copying between pages, for example --There's no immediate consumer for the sparc64 implementation, since busdma there needs neither bounce buffers nor cache maintenance. --I would very much like feedback and testing from experts on non-x86 arches. I only have hardware to test the i386 and amd64 implementations; I've only cross-compiled it for everything else. Some of the non-x86 details, like the Book E powerpc TLB invalidation code, are a bit scary and probably not quite right. Thanks, Jason