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

[Russell King - ARM Linux]

What's the status of these three patches then?  It's been a fortnight
since they were sent, and I've heard nothing about whether they're
going to be applied or not.


On Mon, Apr 18, 2016 at 07:28:15PM +0800, Baoquan He wrote:
> 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

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