From owner-freebsd-arch@freebsd.org Mon Feb 29 16:18:17 2016 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 17786AB86A6 for ; Mon, 29 Feb 2016 16:18:17 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 D5EFF1BA2 for ; Mon, 29 Feb 2016 16:18:16 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by mail-ig0-x22e.google.com with SMTP id z8so81406800ige.0 for ; Mon, 29 Feb 2016 08:18:16 -0800 (PST) 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; bh=mTyMAJpev3LDp5HDizEGt7aWp5weKN8YE6uHJiPDMuA=; b=cuMn3Z2OAl10K9jGPkIyx3qIiJicn8ZMqPl/4wngBIeYsWe9U64e7wSWqfIuEtjNt5 cXsJmP0rsG+ZK4pfkudB3YHkRAXC+2ODcLfXXwlCp+qkxVUI0Mz8u5zw8Kbrdjjikgv6 I3p6QRoHx2xpujvDsEr1dD3brNsTcSdSz9g66T2OZSyRd0cQ4FK9ZLNvWtR76tvRXRht QAbll2Oz7WP4ZmBn5OU2JusdS5FIM85xA6+IxMBMnpaP2B6jBSmMGpyNluMBFY0pE4oR 1bP4Cu1nm4FQ6ndBgjiU0VqxpgATJgaPeb5fuzD2+IfT+323q8EKkp1z9bzEEkKLk3n6 3JRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=mTyMAJpev3LDp5HDizEGt7aWp5weKN8YE6uHJiPDMuA=; b=ImRwYhIwOh8ENp4kkQ6Arm67hfkwLca/ucCkcTj5yEoH+O44XeueeO/oI+CYKz5sdj HpCu580rVjwR2VWZQ63jQa/JBWBSlsUAnqS21Ot074jtEY5WpiE5uGo5o2ogit2ISWv4 R9TNsCRQQBOxk71Gs/xY2BuQXsJREkvXvWPjYlRAwABC+oLvUkHtUphk9ezdUxpIDh4p W1382eGlq16nlr6zdIdBnCTXrtqOH7jyrq2UkANXXlNuUnX3lBihbWaAzmhPPe8tWWNs lFR/1nIiN/z0oOTRJUcvAp46gbL2QViFkkvQkPEziHfdJxLnzZT2dXqbsdgZkYH+Nksr JKMw== X-Gm-Message-State: AD7BkJInjsBjLwR1PxSytWjfjQVQqcy9WGaHD3YPeFpjzJz/Hy0ag7zBgdhoVN8mDOrX5QVHGR2aecSzGxQRrg== MIME-Version: 1.0 X-Received: by 10.50.98.74 with SMTP id eg10mr2978354igb.26.1456762696239; Mon, 29 Feb 2016 08:18:16 -0800 (PST) Received: by 10.64.126.104 with HTTP; Mon, 29 Feb 2016 08:18:16 -0800 (PST) In-Reply-To: References: <20160222121836.GH91220@kib.kiev.ua> <20160224102754.GK91220@kib.kiev.ua> Date: Mon, 29 Feb 2016 17:18:16 +0100 Message-ID: Subject: Re: RF_CACHEABLE flag From: Svatopluk Kraus To: Adrian Chadd Cc: Konstantin Belousov , Justin Hibbits , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Mon, 29 Feb 2016 16:18:17 -0000 On Wed, Feb 24, 2016 at 6:14 PM, Adrian Chadd wrote: > On 24 February 2016 at 02:27, Konstantin Belousov wrote: >> On Tue, Feb 23, 2016 at 02:19:57PM -0600, Justin Hibbits wrote: >>> This really isn't much different from bus_space_map() conceptually. >>> The work involved is pretty much the same, and if this route is deemed >>> the Wrong Way(TM), I'll go that route. >>> >>> Grepping through sys/, only x86 currently implements >>> pmap_change_attr(), and arm has the declaration but no definition that >>> I could see. Writing it wouldn't be difficult of course, there's just >>> not much compelling case for it right now. But, yes, either of these >>> alternatives are acceptable, and I had explored it. Seeing John >>> Baldwin's comment on the phab review, it looks like he wants to go a >>> different (parallel) direction. >> >> If this was not clear from my reply, I did not objected against RF_CACHEABLE, >> but was more to highlight weird needs of seemingly simple architecture, >> which are close to RF_CACHEABLE stuff. And, I think that architectures >> that care about caching modes, should do provide real pmap_change_attr() >> implementation. This might be important e.g. if drm is brought up on >> these platforms. > > heh, on ARM it's not "when". For MIPS it's also now "when". So I guess > yeah, we should implement it. > It's not so simple to change memory attributes on ARM. Some conditions must be met. So, a question is - in which circumstances pmap_change_attr() is used? It's defined like int pmap_change_attr(vm_offset_t va, vm_size_t size, int mode); (1) As memory attributes can be changed on a page basis only, the va and size are arranged according to that in i386 implementation. That's okay. (2) Can the memory be used by somebody else while the attributes are being changed? In other words, can the memory be unmapped temporary?