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

[Brandon Perez <a0225893@xxxxxx>]

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

   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
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users