[PATCH 3/3] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King - ARM Linux]

On Mon, Apr 18, 2016 at 06:32:58PM +0800, Baoquan He wrote:
> On 04/18/16 at 09:36am, Russell King - ARM Linux wrote:
> > On Mon, Apr 18, 2016 at 01:38:20PM +0800, Baoquan He wrote:
> > > On 04/14/16 at 09:00pm, Russell King wrote:
> > > > On PAE systems (eg, ARM LPAE) the vmcore note may be located above
> > > > 4GB physical on 32-bit architectures, so we need a wider type than
> > > > "unsigned long" here.  Arrange for paddr_vmcoreinfo_note() to return
> > > > a phys_addr_t, thereby allowing it to be located above 4GB.
> > > 
> > > At first glance, it sounds great. But I can't imagine a scenario where
> > > on pae system kernel can be located above 4G. As far as I know i386 and
> > > its pae can't do this because the current linux VM implementation can't
> > > allow that. I am not familiar with arm system. So please correct me if
> > > I was wrong.
> > 
> > You are wrong.  That's precisely why this patch exists.
> 
> I don't know arm is different then i386. On i386 the kernel text mapping
> is linear, just as follow:
> 
> #define __phys_addr_nodebug(x)  ((x) - PAGE_OFFSET)
> 
> 
> But arm seems not linear. 
> static inline phys_addr_t __virt_to_phys(unsigned long x)
> {
>         phys_addr_t t;
> 
>         if (sizeof(phys_addr_t) == 4) {
>                 __pv_stub(x, t, "add", __PV_BITS_31_24);
>         } else {
>                 __pv_stub_mov_hi(t);
>                 __pv_add_carry_stub(x, t);
>         }
>         return t;
> }
> 
> So on arm PAE this change makes sense.

No.  This has nothing to do with whether memory is linear or not.  The
above code has nothing to do with that either.  The above code you quote
allows us to efficiently runtime modify the virtual to physical
translation offset, nothing more.

> Besides, I checked kexec/arch/arm/kexec-zImage-arm.c and found function
> locate_hole() is used to find position for arm kernel. 
> 
> unsigned long locate_hole(struct kexec_info *info,
>         unsigned long hole_size, unsigned long hole_align,
>         unsigned long hole_min, unsigned long hole_max, 
>         int hole_end)
> 
> The type unsigned long for hole_max limit the region where arm kernel is
> loaded. So withough modifying this I doubt arm PAE can really be loaded
> above 4G.

Please, stop "doubting" the patches.

I have here a machine which requires these patches, and they're all
tested.  Without these patches, it doesn't work - and in fact trying
to use kexec on the platform takes out userspace due to the OOM killer.
With these patches, it does work - fully.  It has the start of system
memory above 4GB physical, with a non-DMA coherent boot time alias
below 4GB.

On a running system, the kernel ignores the boot alias below 4GB.
Having discussed with Eric, kexec is designed to use the boot time
alias, and we need to teach kexec about the difference between the
boot time alias and the running system memory layout.

That's what these patches are all about.

I've been discussing the problem with Eric on and off over the last
six months, and he's the one who suggested in part the solution
implemented in this series.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.