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

[Baoquan He <bhe@redhat.com>]

On 04/18/16 at 11:52am, Russell King - ARM Linux wrote:
> 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.

OK, thanks for telling this. Learned it.

> 
> > 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.

Got it. Just pass by to have a look:) Since Erci suggested these I stop
making noise right now.

Thanks for telling above knowledge about arm.

Thanks
Baoquan