From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Will Deacon <Will.Deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 1/5] arm/xen: define xen_remap as ioremap_cached
Date: Tue, 4 Jun 2013 14:58:57 +0100 [thread overview]
Message-ID: <20130604135857.GV18614@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20130604112834.GA3234@MacBook-Pro.local>
On Tue, Jun 04, 2013 at 12:28:34PM +0100, Catalin Marinas wrote:
> PROT_PTE_DEVICE and PROT_SECT_DEVICE above don't contain any memory type
> information, just attributes/permission - present, young, dirty and XN:
>
> #define PROT_PTE_DEVICE L_PTE_PRESENT|L_PTE_YOUNG|L_PTE_DIRTY|L_PTE_XN
> #define PROT_SECT_DEVICE PMD_TYPE_SECT|PMD_SECT_AP_WRITE
>
> The memory type is given by the L_PTE_MT_DEV_CACHED and PMD_SECT_WB
> macros. Let's take prot_sect first as it's simpler. For MT_DEVICE_CACHED
> we have:
>
> .prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_WB
>
> For MT_MEMORY we have:
>
> .prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE
>
> The cache policy is added later to MT_MEMORY which is either WB or WBWA
> (based on SMP, no particular reason as these are just processor hints;
> for some historical reasons we enabled WBWA for ARM11MPCore but we could
> leave it on all the time).
They may be reported to be just hints, but SMP, particularly ARM11MPCore,
the SMP guys at ARM Ltd were very particular about _requiring_ and stating
that it is required that WBWA must be used in the page tables for SMP,
and not WB. That suggests while the ARM ARM may say that they're hints,
there's slightly more to it when it comes to SMP, and WBWA is a hard
requirement there.
Indeed, that's something we enforce in the kernel because of the statements
from the SMP development group.
> Similarly for prot_pte, present, young, dirty are the same.
>
> Regarding the type, on ARMv7 (with or without LPAE) we use TEX remapping
> and L_PTE_MT_DEVICE has the same index (3-bit TEX[0], C, B for NMRR/PRRR
> or TEX[2:0] for MAIR0/MAIR1 registers) as Normal Cacheable Writeback
> memory (there is no such thing as Device memory with cacheability
> attributes, only Normal Cacheable memory).
You don't mean L_PTE_MT_DEVICE there. Thankfully, L_PTE_MT_DEVICE doesn't
exist, so it's not that confusing. What you mean is L_PTE_MT_DEV_CACHED,
which _does_ map to "normal cacheable writeback memory" irrespective of
the mappings which the kernel uses for RAM.
However, that mapping type (which is used for MT_DEVICE_CACHED) should
not be used if you really do want normal memory. And using MT_* definitions
_not_ in asm/io.h with ioremap() is really... silly. It's not something
that is intended, nor is it something which I intend to be supportable
into the future on ARM. That's why the definitions are separate - see
the comments in asm/io.h about "types 4 onwards are undefined for
ioremap" - I'm not sure how more explicit to make that statement. And
as I _have_ made the statement, if I see people violating it, I won't
care about their code if/when I decide to change the ioremap() behaviour.
next prev parent reply other threads:[~2013-06-04 13:59 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-03 15:32 [PATCH v2 0/5] Introduce Xen support to ARM64 Stefano Stabellini
2013-06-03 15:33 ` [PATCH v2 1/5] arm/xen: define xen_remap as ioremap_cached Stefano Stabellini
2013-06-04 9:20 ` Ian Campbell
2013-06-04 11:28 ` Catalin Marinas
2013-06-04 11:35 ` Stefano Stabellini
2013-06-04 13:58 ` Russell King - ARM Linux [this message]
2013-06-04 14:14 ` Stefano Stabellini
2013-06-04 16:26 ` Catalin Marinas
2013-06-03 15:33 ` [PATCH v2 2/5] arm64/xen: introduce asm/xen header files on arm64 Stefano Stabellini
2013-06-04 9:24 ` Ian Campbell
2013-06-03 15:33 ` [PATCH v2 3/5] arm64/xen: implement ioremap_cached " Stefano Stabellini
2013-06-03 15:33 ` [PATCH v2 4/5] arm64/xen: use XEN_IO_PROTO_ABI_ARM on ARM64 Stefano Stabellini
2013-06-04 9:25 ` Ian Campbell
2013-06-03 15:33 ` [PATCH v2 5/5] arm64/xen: introduce CONFIG_XEN and hypercall.S " Stefano Stabellini
2013-06-03 16:25 ` Catalin Marinas
2013-06-03 16:37 ` [Xen-devel] " Ian Campbell
2013-06-03 16:43 ` Catalin Marinas
2013-06-03 16:51 ` Stefano Stabellini
2013-06-05 13:21 ` Catalin Marinas
2013-06-04 14:47 ` Konrad Rzeszutek Wilk
2013-06-04 16:27 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130604135857.GV18614@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=Ian.Campbell@citrix.com \
--cc=Will.Deacon@arm.com \
--cc=catalin.marinas@arm.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®