| Message ID | b56c0def845535b41b6c00bffdd9d91de5ddae5c.1414099246.git.geoff@infradead.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Oct 24, 2014 at 12:10:58AM +0100, Geoff Levand wrote: > Change any reference of device tree '/memreserve/' entries in the arm64 > booting.txt to refer to 'reserved-memory nodes'. Reserved-memory nodes > are the preferred method of specifying reserved memory. Per my comments on patch 5, I don't think this change is sufficient. However, we should probably update the document to allow reserved-memory nodes. On an unrelated note we probably need to work out how reserved-memory interacts with the UEFI memory map -- unmappable regions shouldn't be described by UEFI and I hope people don't use reserved-memory as a workaround for broken UEFI tables. Thanks, Mark. > Signed-off-by: Geoff Levand <geoff@infradead.org> > --- > Documentation/arm64/booting.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt > index f3c05b5..7446822 100644 > --- a/Documentation/arm64/booting.txt > +++ b/Documentation/arm64/booting.txt > @@ -196,7 +196,7 @@ following manner: > naturally-aligned 64-bit zero-initalised memory location. > > These CPUs should spin outside of the kernel in a reserved area of > - memory (communicated to the kernel by a /memreserve/ region in the > + memory (communicated to the kernel by a reserved-memory node in the > device tree) polling their cpu-release-addr location, which must be > contained in the reserved region. A wfe instruction may be inserted > to reduce the overhead of the busy-loop and a sev will be issued by > @@ -209,7 +209,7 @@ following manner: > - CPUs with a "psci" enable method should remain outside of > the kernel (i.e. outside of the regions of memory described to the > kernel in the memory node, or in a reserved area of memory described > - to the kernel by a /memreserve/ region in the device tree). The > + to the kernel by a reserved-memory node in the device tree). The > kernel will issue CPU_ON calls as described in ARM document number ARM > DEN 0022A ("Power State Coordination Interface System Software on ARM > processors") to bring CPUs into the kernel. > -- > 1.9.1 > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
On Fri, Oct 24, 2014 at 11:54 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > On Fri, Oct 24, 2014 at 12:10:58AM +0100, Geoff Levand wrote: > > Change any reference of device tree '/memreserve/' entries in the arm64 > > booting.txt to refer to 'reserved-memory nodes'. Reserved-memory nodes > > are the preferred method of specifying reserved memory. > > Per my comments on patch 5, I don't think this change is sufficient. > > However, we should probably update the document to allow reserved-memory > nodes. > > On an unrelated note we probably need to work out how reserved-memory > interacts with the UEFI memory map -- unmappable regions shouldn't be > described by UEFI and I hope people don't use reserved-memory as a > workaround for broken UEFI tables. When booting with UEFI, the boot stub will clear out all memory nodes and (should) clear out reserved regions so that the kernel can use the UEFI memory map as authoritative. g.
On Fri, Oct 24, 2014 at 12:04:00PM +0100, Grant Likely wrote: > On Fri, Oct 24, 2014 at 11:54 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > > > On Fri, Oct 24, 2014 at 12:10:58AM +0100, Geoff Levand wrote: > > > Change any reference of device tree '/memreserve/' entries in the arm64 > > > booting.txt to refer to 'reserved-memory nodes'. Reserved-memory nodes > > > are the preferred method of specifying reserved memory. > > > > Per my comments on patch 5, I don't think this change is sufficient. > > > > However, we should probably update the document to allow reserved-memory > > nodes. > > > > On an unrelated note we probably need to work out how reserved-memory > > interacts with the UEFI memory map -- unmappable regions shouldn't be > > described by UEFI and I hope people don't use reserved-memory as a > > workaround for broken UEFI tables. > > > When booting with UEFI, the boot stub will clear out all memory nodes > and (should) clear out reserved regions so that the kernel can use the > UEFI memory map as authoritative. We clear memory nodes and memreserves currently. I was thinking about reserved-memory nodes (for CMA and such), which we don't currently clear. Mark.
On Fri, Oct 24, 2014 at 1:18 PM, Mark Rutland <mark.rutland@arm.com> wrote: > On Fri, Oct 24, 2014 at 12:04:00PM +0100, Grant Likely wrote: >> On Fri, Oct 24, 2014 at 11:54 AM, Mark Rutland <mark.rutland@arm.com> wrote: >> > >> > On Fri, Oct 24, 2014 at 12:10:58AM +0100, Geoff Levand wrote: >> > > Change any reference of device tree '/memreserve/' entries in the arm64 >> > > booting.txt to refer to 'reserved-memory nodes'. Reserved-memory nodes >> > > are the preferred method of specifying reserved memory. >> > >> > Per my comments on patch 5, I don't think this change is sufficient. >> > >> > However, we should probably update the document to allow reserved-memory >> > nodes. >> > >> > On an unrelated note we probably need to work out how reserved-memory >> > interacts with the UEFI memory map -- unmappable regions shouldn't be >> > described by UEFI and I hope people don't use reserved-memory as a >> > workaround for broken UEFI tables. >> >> >> When booting with UEFI, the boot stub will clear out all memory nodes >> and (should) clear out reserved regions so that the kernel can use the >> UEFI memory map as authoritative. > > We clear memory nodes and memreserves currently. > > I was thinking about reserved-memory nodes (for CMA and such), which we > don't currently clear. We should either clear them, or make sure that they will coexist happily with the UEFI map. I can think of a few situations, like CMA, where still having the reserved-memory node would be a good idea. g.
On Fri, Oct 24, 2014 at 02:54:02PM +0100, Grant Likely wrote: > On Fri, Oct 24, 2014 at 1:18 PM, Mark Rutland <mark.rutland@arm.com> wrote: > > On Fri, Oct 24, 2014 at 12:04:00PM +0100, Grant Likely wrote: > >> On Fri, Oct 24, 2014 at 11:54 AM, Mark Rutland <mark.rutland@arm.com> wrote: > >> > > >> > On Fri, Oct 24, 2014 at 12:10:58AM +0100, Geoff Levand wrote: > >> > > Change any reference of device tree '/memreserve/' entries in the arm64 > >> > > booting.txt to refer to 'reserved-memory nodes'. Reserved-memory nodes > >> > > are the preferred method of specifying reserved memory. > >> > > >> > Per my comments on patch 5, I don't think this change is sufficient. > >> > > >> > However, we should probably update the document to allow reserved-memory > >> > nodes. > >> > > >> > On an unrelated note we probably need to work out how reserved-memory > >> > interacts with the UEFI memory map -- unmappable regions shouldn't be > >> > described by UEFI and I hope people don't use reserved-memory as a > >> > workaround for broken UEFI tables. > >> > >> > >> When booting with UEFI, the boot stub will clear out all memory nodes > >> and (should) clear out reserved regions so that the kernel can use the > >> UEFI memory map as authoritative. > > > > We clear memory nodes and memreserves currently. > > > > I was thinking about reserved-memory nodes (for CMA and such), which we > > don't currently clear. > > We should either clear them, or make sure that they will coexist > happily with the UEFI map. I can think of a few situations, like CMA, > where still having the reserved-memory node would be a good idea. My thinking would be that reservations which the kernel could choose to ignore for whatever reason and use for general allocation (e.g. CMA) make sense, but anything else is nonsense if it overlaps with available memory in the UEFI memory map -- it shouldn't have been there to begin with. I don't know what the best thing to do in that case is. I'd like to explode very loudly during bringup to get vendors to fix their UEFI tables, but in the long run we might just have to reconcile the two and align with the most stringent requirement. Good luck getting another OS working in that case... Mark.
On Fri, Oct 24, 2014 at 3:10 PM, Mark Rutland <mark.rutland@arm.com> wrote: > On Fri, Oct 24, 2014 at 02:54:02PM +0100, Grant Likely wrote: >> On Fri, Oct 24, 2014 at 1:18 PM, Mark Rutland <mark.rutland@arm.com> wrote: >> > On Fri, Oct 24, 2014 at 12:04:00PM +0100, Grant Likely wrote: >> >> On Fri, Oct 24, 2014 at 11:54 AM, Mark Rutland <mark.rutland@arm.com> wrote: >> >> > >> >> > On Fri, Oct 24, 2014 at 12:10:58AM +0100, Geoff Levand wrote: >> >> > > Change any reference of device tree '/memreserve/' entries in the arm64 >> >> > > booting.txt to refer to 'reserved-memory nodes'. Reserved-memory nodes >> >> > > are the preferred method of specifying reserved memory. >> >> > >> >> > Per my comments on patch 5, I don't think this change is sufficient. >> >> > >> >> > However, we should probably update the document to allow reserved-memory >> >> > nodes. >> >> > >> >> > On an unrelated note we probably need to work out how reserved-memory >> >> > interacts with the UEFI memory map -- unmappable regions shouldn't be >> >> > described by UEFI and I hope people don't use reserved-memory as a >> >> > workaround for broken UEFI tables. >> >> >> >> >> >> When booting with UEFI, the boot stub will clear out all memory nodes >> >> and (should) clear out reserved regions so that the kernel can use the >> >> UEFI memory map as authoritative. >> > >> > We clear memory nodes and memreserves currently. >> > >> > I was thinking about reserved-memory nodes (for CMA and such), which we >> > don't currently clear. >> >> We should either clear them, or make sure that they will coexist >> happily with the UEFI map. I can think of a few situations, like CMA, >> where still having the reserved-memory node would be a good idea. > > My thinking would be that reservations which the kernel could choose to > ignore for whatever reason and use for general allocation (e.g. CMA) > make sense, but anything else is nonsense if it overlaps with available > memory in the UEFI memory map -- it shouldn't have been there to begin > with. > > I don't know what the best thing to do in that case is. I'd like to > explode very loudly during bringup to get vendors to fix their UEFI > tables, but in the long run we might just have to reconcile the two and > align with the most stringent requirement. Good luck getting another OS > working in that case... On ACPI platforms this is a non-issue. On UEFI+FDT platforms there are unlikely to be any other operating systems significantly affected by this. g.
diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt index f3c05b5..7446822 100644 --- a/Documentation/arm64/booting.txt +++ b/Documentation/arm64/booting.txt @@ -196,7 +196,7 @@ following manner: naturally-aligned 64-bit zero-initalised memory location. These CPUs should spin outside of the kernel in a reserved area of - memory (communicated to the kernel by a /memreserve/ region in the + memory (communicated to the kernel by a reserved-memory node in the device tree) polling their cpu-release-addr location, which must be contained in the reserved region. A wfe instruction may be inserted to reduce the overhead of the busy-loop and a sev will be issued by @@ -209,7 +209,7 @@ following manner: - CPUs with a "psci" enable method should remain outside of the kernel (i.e. outside of the regions of memory described to the kernel in the memory node, or in a reserved area of memory described - to the kernel by a /memreserve/ region in the device tree). The + to the kernel by a reserved-memory node in the device tree). The kernel will issue CPU_ON calls as described in ARM document number ARM DEN 0022A ("Power State Coordination Interface System Software on ARM processors") to bring CPUs into the kernel.
Change any reference of device tree '/memreserve/' entries in the arm64 booting.txt to refer to 'reserved-memory nodes'. Reserved-memory nodes are the preferred method of specifying reserved memory. Signed-off-by: Geoff Levand <geoff@infradead.org> --- Documentation/arm64/booting.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)