在 2019年1月25日星期五 UTC+8下午4:18:58，J. Kiszka写道：
> On 25.01.19 02:50, JJZhu wrote:
> > 在 2019年1月24日星期四 UTC+8下午5:17:33，J. Kiszka写道：
> >> On 24.01.19 07:47, JJZhu wrote:
> >>> Hi all,
> >>>
> >>> I am using ARM64 Ultrazed board (ZYNQ Ultrascale+ serials). I want to
> >>> allocate memeory in the initialization functions.
> >>>
> >>> I use a simplified malloc and free function from other project.I modified
> >>> it a little on the start address. I use the stack_top as the beginning of
> >>> first available memory address.
> >>>
> >>> Then I tested the malloc functions, it can return correct value according
> >>> to the size we need.
> >>> I can allocate memory from 0x1c000(stack_top) to 0x200000. But when it
> >>> reach 0x200000, The system crashed without any print information.
> >>>
> >>> Is there any limitation about stack size? 0x200000?
> >>
> >> We only map the first 2M during arch_mmu_enable in the inmate. If you want
> >> more
> >> (and changed the inmate config to provide more to the guest), you need to
> >> map
> >> those ranges in your inmate setup yourself (map_range).
> >>
> >>>
> >>> Another question is that if I start another bare-metal inmate, does it
> >>> share the same stack as the first inmate or it has its own stack also
> >>> available from 0x1c000 on it own memory?
> >>
> >> If you create a different config which assigns different physical memory
> >> to the
> >> virtual range of the inmate, there will be no sharing, of course.
> >>
> >> Jan
> >>
> >> --
> >> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> >> Corporate Competence Center Embedded Linux
> >
> > Hi Jan,
> >
> > I have checked the arch_mmu_enable(). It only maps two 0x10000 size of
> > memory.
> >
> > void arch_mmu_enable(void)
> > {
> > unsigned long mair, sctlr;
> >
> > map_range((void*)CONFIG_INMATE_BASE, 0x10000, MAP_CACHED);
> > map_range((void*)COMM_REGION_BASE, PAGE_SIZE, MAP_CACHED);
> >
> > /*
> > * ARMv7: Use attributes 0 and 1 in MAIR0
> > * ARMv8: Use attributes 0 and 1 in MAIR
> > *
> > * Attributes 0: inner/outer: normal memory, outer write-back
> > * non-transient
> > * Attributes 1: device memory
> > */
> > mair = MAIR_ATTR(1, MAIR_ATTR_DEVICE) | MAIR_ATTR(0, MAIR_ATTR_WBRWA);
> > arm_write_sysreg(MAIR, mair);
> >
> > arm_write_sysreg(TRANSL_CONT_REG, TRANSL_CONT_REG_SETTINGS);
> >
> > arm_write_sysreg(TTBR0, page_directory);
> > /* This barrier ensures that TTBR0 is set before enabling the MMU. */
> > instruction_barrier();
> >
> > arm_read_sysreg(SCTLR, sctlr);
> > sctlr |= SCTLR_MMU_CACHES;
> > arm_write_sysreg(SCTLR, sctlr);
> > /* This barrier ensures that the MMU is actually on */
> > instruction_barrier();
> > /* MMU is enabled from now on */
> > }
> >
> > Where is the 2M memory? Can I just change one paremeter somewhere to make
> > it double?
>
> The current implementation of map_range on ARM performs that mapping at 2M
> granularity (HUGE_PAGE_SIZE). So that 64K request is rounded up to 2M.
>
> >
> > For the config file:
> > I have modified the config file which should be enough.
> >
> > /* RAM */ {
> > .phys_start = 0x43000000,
> > .virt_start = 0,
> > .size = 0x10000000,
> > .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> > JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_LOADABLE,
> > },
> >
> > Could you give some more detailed suggestion on where to modify?
>
> Add some map_range call to your main function. That could actually map that
> whole range (map_range(0, 0x10000000, MAP_CACHED)).
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
Hi Jan,
Thank you. It works!
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
