From mboxrd@z Thu Jan 1 00:00:00 1970 From: nicolas.pitre@linaro.org (Nicolas Pitre) Date: Mon, 24 Sep 2012 18:32:22 -0400 (EDT) Subject: [PATCH v3 RESEND 05/17] ARM: LPAE: support 64-bit virt_to_phys patching In-Reply-To: References: <1348242975-19184-1-git-send-email-cyril@ti.com> <1348242975-19184-6-git-send-email-cyril@ti.com> <20120924151305.GA14198@arm.com> <5060C9C6.8080900@ti.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, 24 Sep 2012, Catalin Marinas wrote: > On 24 September 2012 22:20, Nicolas Pitre wrote: > > On Mon, 24 Sep 2012, Cyril Chemparathy wrote: > > > >> On 9/24/2012 11:56 AM, Nicolas Pitre wrote: > >> > On Mon, 24 Sep 2012, Catalin Marinas wrote: > >> > > >> > > On Fri, Sep 21, 2012 at 04:56:03PM +0100, Cyril Chemparathy wrote: > >> > > > This patch adds support for 64-bit physical addresses in virt_to_phys() > >> > > > patching. This does not do real 64-bit add/sub, but instead patches in > >> > > > the > >> > > > upper 32-bits of the phys_offset directly into the output of > >> > > > virt_to_phys. > >> > > > >> > > So this assumes that for the kernel linear mapping, all the physical > >> > > addresses have the same upper 32-bit. That's a good optimisation but I > >> > > haven't seen this check when calculating lowmem in sanity_check_meminfo. > >> > > Someone may build platform with memory starting at 3GB and going across > >> > > the 4GB limit. > >> > > >> > Good point. We better get an early warning if that happens. > >> > > >> > >> Thanks. > >> > >> I'm thinking of splitting the bank at the 32-bit boundary in such an event, > >> assuming that the remaining memory should be usable as highmem. > > > > No. That's not the point here. > > > > Let's suppose a system with 1GB of physical RAM starting at 0xe0000000. > > > > In this case there is no need for highmem. However the v2p patching > > code in the LPAE case assumes the high bits of a physical address are > > always the same which wouldn't be the case in this hypothetical example. > > > > We want to make sure the kernel won't boot if a system with physical RAM > > crossing the 4GB address mark is encountered. > > I think that's too restrictive. The case with 1 or 2GB below 4GB limit > and the rest of the RAM above is a valid one. Valid: sure. Likely: probably not. That would complicate address decoding in hardware for little gain. > For such configurations > we just limit the lowmem to the memory within 4GB and leave the rest > as highmem. We don't want to limit lowmem. The lowmem is very precious memory and we want to maximize its size. In that case it is probably best to implement a real patchable 64-bit addition rather than artificially restricting the lowmem size. Nicolas