From owner-freebsd-arch@freebsd.org Mon Feb 29 22:20:16 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 B0825AB95B1 for ; Mon, 29 Feb 2016 22:20:16 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 7ED05FF3 for ; Mon, 29 Feb 2016 22:20:16 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by mail-ig0-x235.google.com with SMTP id y8so6671343igp.0 for ; Mon, 29 Feb 2016 14:20: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=esBd2+Bl0NOCt0y8OxCMYT2Z6+6e/J4JQuBk+92nI8I=; b=eV/p22EMmne4n05EJi/1+3DCqFuID/iaxlZBOBkUXGTGlEnpFuqytMdfoWJb0B4VK+ STHUQ6LywIetsO+vlLA+2CfYveN27onIGgi9UYgPSio+91Fj1a7YcxTVt7qgMeVAz2mN 6lEIiAGwVVBgeVJ8LT5pIJr7/Ts6zsDNvsvCGVFcn9oVXZ3eLshgWcM0xK9DvBokR5+z R/yT4ctCrPlpSFFM/PXpt23f5kvKynCGAc+dyt5nxG7Lrel94JOIgBQSfGAm/h9VFMla 9+U/a1sDWW6W5Zb5JcQ2/narEYwxNmpYPUt1qhiVVBPkI8iXVoGoZvN5xvbKZJvoTxE1 hkhQ== 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=esBd2+Bl0NOCt0y8OxCMYT2Z6+6e/J4JQuBk+92nI8I=; b=mWLr0hg6Q7vNPYpqn3LHhBGX0bRHP5EkVAhmF3PM3rsNCDNC78pzG+FHmrVPIRPQWL 71VutWGxVdnqTxI3FX7+3zNKaoY76ti+mL6QnNvM7PYE23qhvPCIhaaWG4Tbu5bNf822 +73/IlWNuu9c0d0kt5Xtd3zRwasVSXAO7iZxsJ9UugzzJG15VlHRxsliXQf7tcNb7ZqV LTTMz2/gOBri8qFr2+saNyoMCjb0uDeI9cIVut+c2linQyC6b9OsR/9WzdmvY4Hkg2SL NuaNv7lX1Hju4rdAy9mAupmNaKLpVjIIbx0Z67UtF7Hq6WMUgpPZmDicQRQGh6LOlgS4 ZhoQ== X-Gm-Message-State: AD7BkJL62pf3RKsVBkkKMOkNGd7XSc79MFK3SPrQH1Pa+VMMO6g+r15pM4iasD1DXwf8tH5ZpN/2gBRceU47zA== MIME-Version: 1.0 X-Received: by 10.50.28.20 with SMTP id x20mr281619igg.19.1456784415920; Mon, 29 Feb 2016 14:20:15 -0800 (PST) Received: by 10.64.126.104 with HTTP; Mon, 29 Feb 2016 14:20:15 -0800 (PST) In-Reply-To: <20160229163545.GW67250@kib.kiev.ua> References: <20160222121836.GH91220@kib.kiev.ua> <20160224102754.GK91220@kib.kiev.ua> <20160229163545.GW67250@kib.kiev.ua> Date: Mon, 29 Feb 2016 23:20:15 +0100 Message-ID: Subject: Re: RF_CACHEABLE flag From: Svatopluk Kraus To: Konstantin Belousov Cc: 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 22:20:16 -0000 On Mon, Feb 29, 2016 at 5:35 PM, Konstantin Belousov wrote: > On Mon, Feb 29, 2016 at 05:18:16PM +0100, Svatopluk Kraus wrote: >> 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? > > Is this for the change of pte through invalidation ? In other words, > do you mean, is it fine to temporary unmap the range during the > pmap_change_attr() execution ? Yep, the question was about that. > > If yes, it is fine for uses of the function in the DRM code, since > it is utilized during a setup of things like GTT or buffers, and no > other accesses to the memory could happen until the setup is finished. > > I noted that function is used by several network drivers as well, and > by ntb. It seem that cxgbe and mxge also use it during setup. The pmap_change_attr() was implemented in (new) armv6 pmap, but was removed before the pmap was committed. It was not sure when the function is used, and if even implemented right. It was about two years ago. Now, with better knowledge and information you provided, it should be possible to implement it again.