From owner-freebsd-arch@FreeBSD.ORG Wed Apr 29 19:59:05 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 983235A0; Wed, 29 Apr 2015 19:59:05 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 5AB801FDA; Wed, 29 Apr 2015 19:59:05 +0000 (UTC) Received: by igblo3 with SMTP id lo3so127421146igb.1; Wed, 29 Apr 2015 12:59:02 -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=7Q2lep1yKgOp92i7Jdy38JoyONV+nE+5XTwrfLLxzoI=; b=VPN9c9PYvN3SoDQXW8WhgzcdR1qW7RKl8CrP+jmzU+6iGnFjxlfVpFKIBRvky0u8Jv IgGeqQ3ImTLeI/JfLuTk+XEIKX3P9UMOyDhhXppT5mVMDzgr71FIjpnpuq1oT4qdFHI5 kRaX6HqJYygTczNV2x7S/AEvcUl1V5EqRLI+YIR5ZP53hFUuiL3AOnVQe9Ur8iEuoMOK t4HpM8XnAmO3TpXwc02WCXLGXb/vAOjtNVafvfkGYrgKOxjh/2Zp7nH66FB00X7nzXCv R0ktxAahRQ2iKIvmCwXzWr5iYDgH2REsPI3wNL8F8Gt8QB34B4LGeN4n1LX/6P1gT2nW 2afQ== MIME-Version: 1.0 X-Received: by 10.50.41.8 with SMTP id b8mr29704345igl.38.1430337542406; Wed, 29 Apr 2015 12:59:02 -0700 (PDT) Received: by 10.36.106.70 with HTTP; Wed, 29 Apr 2015 12:59:02 -0700 (PDT) In-Reply-To: <20150429193337.GQ2390@kib.kiev.ua> References: <38574E63-2D74-4ECB-8D68-09AC76DFB30C@bsdimp.com> <1761247.Bq816CMB8v@ralph.baldwin.cx> <20150429132017.GM2390@kib.kiev.ua> <20150429165432.GN2390@kib.kiev.ua> <20150429185019.GO2390@kib.kiev.ua> <20150429193337.GQ2390@kib.kiev.ua> Date: Wed, 29 Apr 2015 14:59:02 -0500 Message-ID: Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space From: Jason Harmening To: Konstantin Belousov Cc: Svatopluk Kraus , John Baldwin , Adrian Chadd , Warner Losh , 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: Wed, 29 Apr 2015 19:59:05 -0000 > > 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. > Oh, yes, sorry. There were a couple of whitespace changes there, but nothing of consequence. > 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. > Yes, you are right. Regardless of whatever logic the cache uses (or doesn't use), FreeBSD's page-coloring scheme should prevent that. > > 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. > Since VIPT cache operations require a virtual address, I'm wondering about the case where different processes are running on different cores, and the same UVA corresponds to a completely different physical page for each of those processes. If the d-cache for each core contains that UVA, then what does it mean when one core issues a flush/invalidate instruction for that UVA? Admittedly, there's a lot I don't know about how that's supposed to work in the arm/mips SMP world. For all I know, the SMP targets could be fully-snooped and we don't need to worry about cache maintenance at all.