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
