From: Mark Rutland <mark.rutland@arm.com>
To: Grant Likely <grant.likely@linaro.org>
Cc: "Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Geoff Levand <geoff@infradead.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
Marc Zyngier <Marc.Zyngier@arm.com>,
"christoffer.dall@linaro.org" <christoffer.dall@linaro.org>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 05/10] arm64: Convert dts to use reserved-memory nodes
Date: Fri, 24 Oct 2014 13:27:38 +0100 [thread overview]
Message-ID: <20141024122738.GH24265@leverpostej> (raw)
In-Reply-To: <CACxGe6szzOXHkK9ukpcSBZgeyy5AgX3+7PgQseBnB9XWYLj-PQ@mail.gmail.com>
On Fri, Oct 24, 2014 at 11:59:38AM +0100, Grant Likely wrote:
> On Fri, Oct 24, 2014 at 11:51 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Oct 24, 2014 at 12:10:58AM +0100, Geoff Levand wrote:
> >> Device tree regions described by /memreserve/ entries are not available in
> >> /proc/device-tree, and hence are not available to user space utilities that use
> >> /proc/device-tree. In order for these regions to be available, convert any
> >> arm64 DTS files using /memreserve/ entries to use reserved-memory nodes.
> >
> > The limitation here is in the kernel (and a partially in userspace), so
> > modifying the dts files is a workaround rather than a fix.
> >
> > It's perfectly valid for people to remain using /memreserve/, so this
> > isn't sufficient. There are also existing DTBs using /memreserve/ which
> > we can't rely on being modified to use reserved-memory.
> >
> > I think we need to expose memreserves to userspace somehow, potentially
> > along with other DTB header fields. Grant, ideas?
>
> Yes, I suggested the same thing to Geoff in a separate thread. Here's
> what I wrote:
>
> >> Geoff Levand wrote:
> >>> I did some work on this and I think we just need to convert all the
> >>> arm64 dts from /memreserve/ to reserved-memory nodes and update the
> >>> arm64 booting.txt to specify using reserved-memory. I'll prepare a
> >>> patch for it.
> >>
> >> I don't think that is going to be entirely sufficient. There will be
> >> platforms that don't get converted over, and this is a generic problem
> >> that covers all architectures using DT, not just aarch64. The solution
> >> probably needs to include exposing the /memreserve/ sections to
> >> userspace. I can see two ways to do this:
> >>
> >> 1) Create a new property in /sysfs with all the memreserve sctions
> >> 2) Live-modify the device tree to put the memreserve data into a node
> >> at boot time.
> >>
> >> Option 2 is probably the most generic solution, but it will require
> >> some care to make sure there aren't any overlaps if a reserved-memory
> >> node already exists.
I would prefer the former currently. While I currently believe that
modifying the tree is something we're going to have to do for stateful
properties, it's not someting I want to have to do unless absolutely
necessary.
> >>
> >> g.
> >
> > For reference, here is an old conversation about this exact thing.
> > Reading through it, the opinions I expressed then don't necessarily
> > match what I think now. I still don't think it is a good idea to
> > expose the physical address of the old .dtb blob, but I do agree that
> > the memreserve sections need to be exposed.
> >
> > https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-July/083993.html
Another option would be to expose the original DTB as a (read-only)
binary file somewhere. That might interact poorly with live tree
modification in future, however.
Mark.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 05/10] arm64: Convert dts to use reserved-memory nodes
Date: Fri, 24 Oct 2014 13:27:38 +0100 [thread overview]
Message-ID: <20141024122738.GH24265@leverpostej> (raw)
In-Reply-To: <CACxGe6szzOXHkK9ukpcSBZgeyy5AgX3+7PgQseBnB9XWYLj-PQ@mail.gmail.com>
On Fri, Oct 24, 2014 at 11:59:38AM +0100, Grant Likely wrote:
> On Fri, Oct 24, 2014 at 11:51 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Oct 24, 2014 at 12:10:58AM +0100, Geoff Levand wrote:
> >> Device tree regions described by /memreserve/ entries are not available in
> >> /proc/device-tree, and hence are not available to user space utilities that use
> >> /proc/device-tree. In order for these regions to be available, convert any
> >> arm64 DTS files using /memreserve/ entries to use reserved-memory nodes.
> >
> > The limitation here is in the kernel (and a partially in userspace), so
> > modifying the dts files is a workaround rather than a fix.
> >
> > It's perfectly valid for people to remain using /memreserve/, so this
> > isn't sufficient. There are also existing DTBs using /memreserve/ which
> > we can't rely on being modified to use reserved-memory.
> >
> > I think we need to expose memreserves to userspace somehow, potentially
> > along with other DTB header fields. Grant, ideas?
>
> Yes, I suggested the same thing to Geoff in a separate thread. Here's
> what I wrote:
>
> >> Geoff Levand wrote:
> >>> I did some work on this and I think we just need to convert all the
> >>> arm64 dts from /memreserve/ to reserved-memory nodes and update the
> >>> arm64 booting.txt to specify using reserved-memory. I'll prepare a
> >>> patch for it.
> >>
> >> I don't think that is going to be entirely sufficient. There will be
> >> platforms that don't get converted over, and this is a generic problem
> >> that covers all architectures using DT, not just aarch64. The solution
> >> probably needs to include exposing the /memreserve/ sections to
> >> userspace. I can see two ways to do this:
> >>
> >> 1) Create a new property in /sysfs with all the memreserve sctions
> >> 2) Live-modify the device tree to put the memreserve data into a node
> >> at boot time.
> >>
> >> Option 2 is probably the most generic solution, but it will require
> >> some care to make sure there aren't any overlaps if a reserved-memory
> >> node already exists.
I would prefer the former currently. While I currently believe that
modifying the tree is something we're going to have to do for stateful
properties, it's not someting I want to have to do unless absolutely
necessary.
> >>
> >> g.
> >
> > For reference, here is an old conversation about this exact thing.
> > Reading through it, the opinions I expressed then don't necessarily
> > match what I think now. I still don't think it is a good idea to
> > expose the physical address of the old .dtb blob, but I do agree that
> > the memreserve sections need to be exposed.
> >
> > https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-July/083993.html
Another option would be to expose the original DTB as a (read-only)
binary file somewhere. That might interact poorly with live tree
modification in future, however.
Mark.
next prev parent reply other threads:[~2014-10-24 12:27 UTC|newest]
Thread overview: 141+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-23 23:10 [PATCH 00/10] arm64 kexec kernel patches V5 Geoff Levand
2014-10-23 23:10 ` Geoff Levand
2014-10-23 23:10 ` [PATCH 04/10] arm64: Add EL2 switch to soft_restart Geoff Levand
2014-10-23 23:10 ` Geoff Levand
2014-10-24 10:57 ` Mark Rutland
2014-10-24 10:57 ` Mark Rutland
2014-10-31 23:47 ` Geoff Levand
2014-10-31 23:47 ` Geoff Levand
2014-10-23 23:10 ` [PATCH 01/10] arm64/kvm: Fix assembler compatibility of macros Geoff Levand
2014-10-23 23:10 ` Geoff Levand
2014-10-24 9:24 ` Mark Rutland
2014-10-24 9:24 ` Mark Rutland
2014-10-27 12:13 ` Will Deacon
2014-10-27 12:13 ` Will Deacon
2014-10-27 12:45 ` Christoffer Dall
2014-10-27 12:45 ` Christoffer Dall
2014-10-31 23:06 ` [PATCH V2 " Geoff Levand
2014-10-31 23:06 ` Geoff Levand
2014-10-23 23:10 ` [PATCH 05/10] arm64: Convert dts to use reserved-memory nodes Geoff Levand
2014-10-23 23:10 ` Geoff Levand
2014-10-24 10:51 ` Mark Rutland
2014-10-24 10:51 ` Mark Rutland
2014-10-24 10:59 ` Grant Likely
2014-10-24 10:59 ` Grant Likely
2014-10-24 12:27 ` Mark Rutland [this message]
2014-10-24 12:27 ` Mark Rutland
2014-10-24 14:45 ` Grant Likely
2014-10-24 14:45 ` Grant Likely
2014-10-31 23:44 ` Geoff Levand
2014-10-31 23:44 ` Geoff Levand
2014-11-03 20:02 ` Mark Rutland
2014-11-03 20:02 ` Mark Rutland
2014-11-03 22:26 ` Rob Herring
2014-11-03 22:26 ` Rob Herring
2014-11-04 11:35 ` Mark Rutland
2014-11-04 11:35 ` Mark Rutland
2014-11-04 11:37 ` Grant Likely
2014-11-04 11:37 ` Grant Likely
2014-10-23 23:10 ` [PATCH 08/10] arm64/kexec: Add core kexec support Geoff Levand
2014-10-23 23:10 ` Geoff Levand
2014-10-24 10:28 ` Mark Rutland
2014-10-24 10:28 ` Mark Rutland
2014-11-13 2:19 ` Geoff Levand
2014-11-13 2:19 ` Geoff Levand
2014-11-17 16:38 ` Mark Rutland
2014-11-17 16:38 ` Mark Rutland
2014-11-17 20:20 ` Geoff Levand
2014-11-17 20:20 ` Geoff Levand
2014-11-07 11:01 ` Arun Chandran
2014-11-07 11:01 ` Arun Chandran
2014-11-12 21:54 ` Geoff Levand
2014-11-13 9:52 ` Arun Chandran
2014-11-17 3:52 ` Dave Young
2014-10-23 23:10 ` [PATCH 03/10] arm64: Add new hcall HVC_CALL_FUNC Geoff Levand
2014-10-23 23:10 ` Geoff Levand
2014-10-23 23:10 ` [PATCH 07/10] arm64: Move proc-macros.S to include/asm Geoff Levand
2014-10-23 23:10 ` Geoff Levand
2014-10-23 23:10 ` [PATCH 02/10] arm64: Convert hcalls to use ISS field Geoff Levand
2014-10-23 23:10 ` Geoff Levand
2014-10-23 23:10 ` [PATCH 06/10] arm64: Update booting.txt to reserved-memory nodes Geoff Levand
2014-10-23 23:10 ` Geoff Levand
2014-10-24 10:54 ` Mark Rutland
2014-10-24 10:54 ` Mark Rutland
2014-10-24 11:04 ` Grant Likely
2014-10-24 11:04 ` Grant Likely
2014-10-24 12:18 ` Mark Rutland
2014-10-24 12:18 ` Mark Rutland
2014-10-24 13:54 ` Grant Likely
2014-10-24 13:54 ` Grant Likely
2014-10-24 14:10 ` Mark Rutland
2014-10-24 14:10 ` Mark Rutland
2014-10-24 14:47 ` Grant Likely
2014-10-24 14:47 ` Grant Likely
2014-10-23 23:10 ` [PATCH 10/10] arm64/kexec: Add pr_devel output Geoff Levand
2014-10-23 23:10 ` Geoff Levand
2014-10-23 23:10 ` [PATCH 09/10] arm64/kexec: Enable kexec in the arm64 defconfig Geoff Levand
2014-10-23 23:10 ` Geoff Levand
2014-10-24 10:31 ` Mark Rutland
2014-10-24 10:31 ` Mark Rutland
2014-10-31 23:50 ` Geoff Levand
2014-10-31 23:50 ` Geoff Levand
2014-11-03 20:05 ` Mark Rutland
2014-11-03 20:05 ` Mark Rutland
2014-11-04 1:49 ` Geoff Levand
2014-11-04 1:49 ` Geoff Levand
2014-10-31 7:52 ` [PATCH 00/10] arm64 kexec kernel patches V5 Dave Young
2014-10-31 7:52 ` Dave Young
2014-10-31 23:25 ` Geoff Levand
2014-10-31 23:25 ` Geoff Levand
2014-11-06 2:01 ` Dave Young
2014-11-06 2:01 ` Dave Young
2014-11-13 8:37 ` Dave Young
2014-11-13 8:37 ` Dave Young
2014-11-13 23:50 ` Geoff Levand
2014-11-13 23:50 ` Geoff Levand
2014-11-17 3:49 ` Dave Young
2014-11-17 3:49 ` Dave Young
2014-11-03 19:46 ` Mark Rutland
2014-11-03 19:46 ` Mark Rutland
2014-11-06 1:56 ` Dave Young
2014-11-06 1:56 ` Dave Young
2014-11-06 15:08 ` Mark Rutland
2014-11-06 15:08 ` Mark Rutland
2014-11-07 0:41 ` Grant Likely
2014-11-07 0:41 ` Grant Likely
2014-11-07 10:16 ` Mark Rutland
2014-11-07 10:16 ` Mark Rutland
2014-11-07 10:41 ` Ard Biesheuvel
2014-11-07 10:41 ` Ard Biesheuvel
2014-11-07 10:45 ` Ard Biesheuvel
2014-11-07 10:45 ` Ard Biesheuvel
2014-11-07 10:46 ` Ard Biesheuvel
2014-11-07 10:46 ` Ard Biesheuvel
2014-11-07 11:35 ` Mark Rutland
2014-11-07 11:35 ` Mark Rutland
2014-11-07 11:42 ` Ard Biesheuvel
2014-11-07 11:42 ` Ard Biesheuvel
2014-11-07 22:34 ` Grant Likely
2014-11-07 22:34 ` Grant Likely
2014-11-06 12:16 ` Arun Chandran
2014-11-06 12:16 ` Arun Chandran
2014-11-06 15:28 ` Mark Rutland
2014-11-06 15:28 ` Mark Rutland
2014-11-06 16:13 ` Arun Chandran
2014-11-06 16:13 ` Arun Chandran
2014-11-06 18:25 ` Geoff Levand
2014-11-06 18:25 ` Geoff Levand
2014-11-07 6:26 ` Arun Chandran
2014-11-07 6:26 ` Arun Chandran
2014-11-06 18:39 ` Mark Rutland
2014-11-06 18:39 ` Mark Rutland
2014-11-07 6:36 ` Arun Chandran
2014-11-07 6:36 ` Arun Chandran
2014-11-10 7:17 ` Dave Young
2014-11-10 7:17 ` Dave Young
2014-11-10 8:35 ` Arun Chandran
2014-11-10 8:35 ` Arun Chandran
2014-11-10 9:24 ` Dave Young
2014-11-10 9:24 ` Dave Young
2014-11-12 9:56 ` Dave Young
2014-11-12 9:56 ` Dave Young
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=20141024122738.GH24265@leverpostej \
--to=mark.rutland@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=Ian.Campbell@citrix.com \
--cc=Marc.Zyngier@arm.com \
--cc=Will.Deacon@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=geoff@infradead.org \
--cc=grant.likely@linaro.org \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=stefano.stabellini@eu.citrix.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.