Hi Julien,
Thank you for your response. I will try and post a log for you. I have
been switching back and forth between configurations and need to take a new
one.
The board has 4GB of memory. Uboot places the kernel/initramfs/dtb in the
0x8000_0000 region but then the kernel switches its code/data over to a
0x8_0000_0000 range via the pv-fixup-asm.S assembly code called from
early_paging_init in arch/arm/mm/mmu.c. That code is exclusive to the
keystone in the 4.19 kernel when "CONFIG_ARM_PV_FIXUP" and "ARM_LPAE" are
enabled in the kernel . The upper 2GB of memory is above 0xFFFF_FFFF so
LPAE is required.
/proc/iomem looks like this without running xen after the switch and the
kernel boots:
80000000 - 9fffffff : System RAM (boot alias)
c8000000 - ffffffff : System RAM (boot alias)
800000000 - 1fffffff : System RAM
800008000-800dfffff : Kernel Code
801000000-80108ab3f : Kernel data
848000000-8ffffffff : System RAM
I was able to duplicate this issue with a build of your latest "master"
repository from this morning.
On Mon, Jun 1, 2020 at 9:29 AM Julien Grall <jul...@xen.org> wrote:
> Hello,
>
> I have a few questions in order to understand a bit more your problem.
>
> On 01/06/2020 13:38, CodeWiz2280 wrote:
> > Hello, I am using a Texas Instruments K2E Keystone Eval board with Linux
> > 4.19.59. It has a 32-bit ARM Cortex A15 processor. There is keystone
> > specific code in the kernel in arch/arm/mm/pv-fixup-asm.s that executes
> > during early_paging_init for LPAE support. This causes the kernel to
> > switch its running 32-bit address space to a 36-bit address space and
> > the hypervisor traps repeatedly and stops it from booting.
>
> Without any log it is going to be difficult to help. Could you post the
> hypervisor log when debug is enabled?
>
> > I suspect
> > this is because Xen only allowed for the original 32-bit memory range
> > specified by the dom0 device tree.
>
> How much RAM did you give to your Dom0?
>
> > The 36-bit LPAE address is a fixed
> > offset from the 32-bit address and is not physically different memory.
>
> I am not sure to understand this. Are you suggesting that the kernel is
> trying to relocate itself in a different part of the physical memory?
>
> Can you provide more details on the fixed offset?
>
> >
> > Can you suggest any way to get through this problem? I am using the
> > master branch of xen from earlier this year.
>
> Can you provide the exact baseline your are using? Did make any changes
> on top?
>
> > Any help is greatly
> > appreciated.
> Best regards,
>
> --
> Julien Grall
>
