[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-users] [Xen-Users] Issues Changing the Dom0 Memory Size (Boot-time)

  • To: <xen-users@xxxxxxxxxxxxx>
  • From: Brandon Perez <a0225893@xxxxxx>
  • Date: Wed, 29 Jul 2015 17:51:23 -0400
  • Delivery-date: Wed, 29 Jul 2015 21:52:44 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>

Hello All,

    To begin, here's my system setup:
        - Hardware: TI DRA72 Chip, Arm Cortex A15
        - Xen:
            - Version: 4.6-unstable
            - Compiled from source, with some local changes
            - Branch: master
        - Linux Kernel:
            - Version: 3.14
            - Compiled From source, with some local changes
            - Repo: git://git.omapzoom.org/kernel/omap.git
            - Branch: android-3.14-6AL.1.0
            - Commit: 7b2f1133857414b96927c06f08ed6c440f5472e7

I'm experiencing some issues when I try to change the initial amount of memory allocated to Dom0 by Xen, using the "dom0_mem" parameter on the command line. I know that 128 MB is the traditional size to use for Dom0, but my Dom0 needs some additional memory due to large CMA areas that are reserved by coprocessors on the chip.

The chip I'm using has a total of 1GB of memory. The target size I'm shooting for is 256 MB. However, this isn't the only size that causes me issues. For most other sizes, even if they are smaller, I have issues booting the kernel. It crashes almost immediately. Some other sizes I have tried: 64 MB, 192 MB, 224 MB, 512 MB. The only other size I could get to work was 132 MB. I tried other sizes too, but the choice of sizes is of course limited as per [1]

I've attached the boot log from when I boot with 256 MB of memory. The extra print at the end was a printk I added to do_trap_hypervisor().

(XEN) Instruction abort from kernel. regs->pc: 0x97a00000, regs->hsr.ec: 32, regs->hsr.iss=0x0000000e

As you can see from the log, 0x97a00000 is the entry point of the Dom0 kernel. I've stepped through the code with a debugger to confirm that this is the source of the fault. The execution of the first instruction in the kernel is causing a prefetch abort.

Looking at the ISS bits, this indicates that the problem comes from improper permissions on that page. Since the kernel doesn't even get to run a single instruction, this leads me to believe that the problem is likely coming from Xen, somehow related to allocate_memory_11(). It's odd that 128 MB works, but any other size, even if its only on a single memory bank like 128 MB, fails.

The only difference between the 128 MB and 256 MB boots is that the zImage is relocated to a different VA than the 128 MB. However, when booting with 64 MB, the zImage VA is the same as the 128 MB boot, but the same issue occurs.

   I've attached the boot logs from 64 MB, 128 MB, and 256 MB boots.

I was hoping to get some guidance on what might be causing this bug before trying to dive deeper into the code.


   Brandon Perez

[1] http://xen.markmail.org/message/ldamhobnot5jfdnc#query:+page:1+mid:6chbukafg5wn2ewe+state:results

Attachment: boot_64.log
Description: Text Data

Attachment: boot_128.log
Description: Text Data

Attachment: boot_256.log
Description: Text Data

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.