linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] arm64: reimplement page_is_ram() using memblock and UEFI memory map
Date: Thu, 12 Nov 2015 16:03:29 +0000	[thread overview]
Message-ID: <20151112160329.GE26564@leverpostej> (raw)
In-Reply-To: <CAKv+Gu8oYv1Ad=n+dgM5o-DTs-xSdSrv9RaDJEu_cQvppLssfw@mail.gmail.com>

On Thu, Nov 12, 2015 at 04:40:23PM +0100, Ard Biesheuvel wrote:
> On 12 November 2015 at 16:31, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> > On Thu, 29 Oct, at 02:40:58PM, Ard Biesheuvel wrote:
> >> This patch overrides the __weak default implementation of page_is_ram(),
> >> which uses string comparisons to find entries called 'System RAM' in
> >> /proc/iomem. Since we used the contents of memblock to create those entries
> >> in the first place, let's use memblock directly.
> >>
> >> Also, since the UEFI memory map may describe regions backed by RAM that are
> >> not in memblock (i.e., reserved regions that were removed from the linear
> >> mapping), check the pfn against the UEFI memory map as well.
> >>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> ---
> >>  arch/arm64/mm/mmu.c | 34 ++++++++++++++++++++
> >>  1 file changed, 34 insertions(+)
> >
> > Am I correct in thinking that the purpose of this series is just to
> > placate acpi_os_ioremap() on arm64, and its use of page_is_ram()?
> >
> 
> That is currently the primary user, but we need this information for
> other purposes as well. One example is /dev/mem, which is used for
> both devices and memory (for instance, tools like dmidecode rely
> heavily on it). When using it to access a memory region that we
> punched out of the linear mapping, we should typically not map it as a
> device, since unaligned accesses cause faults in that case.
> 
> In summary, it would be nice if we could preserve the 'is ram"
> annotation for regions that are not covered by the linear mapping.
> 
> > While there aren't many users of page_is_ram() right now, I can see
> > how in the future if new users are added they'd be extremely confused
> > to find that page_is_ram(pfn) returns true but 'pfn' isn't accessible
> > by the kernel proper.
> >
> 
> Well, who knows. page_is_ram() is poorly documented, and so is the
> 'System RAM' iomem annotation that its default implementation relies
> on.

Sorry if this is a bit of a derailment, but perhaps now is a good
opportunity to introduce something like:

#ifndef page_is_linear_mapped
#define page_is_linear_mapped page_is_ram
#endif

With documentation as to the semantic difference, and a conversion of
existing users.

Thanks,
Mark.

  reply	other threads:[~2015-11-12 16:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-29 13:40 [PATCH 0/3] remove UEFI reserved regions from the linear mapping Ard Biesheuvel
2015-10-29 13:40 ` [PATCH 1/3] arm64/efi: set EFI_MEMMAP bit only after mapping the memory map Ard Biesheuvel
2015-11-12 15:14   ` Matt Fleming
2015-10-29 13:40 ` [PATCH 2/3] arm64: reimplement page_is_ram() using memblock and UEFI " Ard Biesheuvel
2015-11-12 15:31   ` Matt Fleming
2015-11-12 15:40     ` Ard Biesheuvel
2015-11-12 16:03       ` Mark Rutland [this message]
2015-11-12 16:06         ` Ard Biesheuvel
2015-10-29 13:40 ` [PATCH 3/3] arm64/efi: memblock_remove() rather than _reserve UEFI reserved memory Ard Biesheuvel
2015-11-12 15:55 ` [PATCH 0/3] remove UEFI reserved regions from the linear mapping Mark Rutland
2015-11-12 16:01   ` Ard Biesheuvel
2015-11-12 16:13     ` Mark Rutland
2015-11-12 16:30       ` Ard Biesheuvel

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=20151112160329.GE26564@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).