[PATCH v3 RESEND 05/17] ARM: LPAE: support 64-bit virt_to_phys patching
Nicolas Pitre
nicolas.pitre at linaro.org
Mon Sep 24 18:32:22 EDT 2012
On Mon, 24 Sep 2012, Catalin Marinas wrote:
> On 24 September 2012 22:20, Nicolas Pitre <nicolas.pitre at linaro.org> 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
More information about the linux-arm-kernel
mailing list