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

Re: [Xen-devel] [PATCH ARM v6 00/14] mini-os: initial ARM support



Hi Thomas,

On 16/07/14 12:07, Thomas Leonard wrote:
This series is based on Karim's ARM support commits, further broken up into
smaller patches.

The comments from last time should be addressed now, plus a few other things:

- The series is rebased on staging, dropping patches that have already been
   applied.

- The changes have been further split into smaller patches to ease reviewing.
   Note that the build system isn't changed to allow building the new code until
   patch 13.

- Define BUG to cause an undefined instruction fault. This lets us us dump the
   registers.

- Renamed stack to _boot_stack for clarity.

- Include kernel.h from arm/os.h. This is for consistency with x86/os.h
   and is needed to compile with lwIP.

- Moved SVC stack to first 16KB of RAM (provides some protection against
   stack overlow corrupting memory).

- Put translation table in second 16KB (simplifies boot code).

- Moved shared_info_page and irqstack to .bss section (smaller image).

- Moved __bss_start and _edata inside section in linker script.
   The linker adds non-listed sections, such as .got, just before .bss.
   This meant that we accidentally zeroed those out too.

- Enable floating point unit.

- Require only minimum FDT property lengths (requested by Ian Campbell).

Addressed Julien Grall's comments:

- Get hypercall numbers from xen.h.
- Avoid duplicating the definition of _start's virtual address.
- Moved definition of physical_address_offset from asm to C.
- Added paddr_t type to represent physical addresses.
- Added comments explaining the lengths when checking FDT properties.
- Fixed (commented) DEBUG macro.
- Drop check for arm,cortex-a9-gic.

There are two assumptions the code makes that may need changing in the future, 
but
which hopefully don't need to hold up this initial support:

- The assumption that the kernel will be loaded at start of RAM + 0x8000.

- The assumption that Xen will mark the GIC address range as device memory.
   This should probably be fixed when the C code gains the ability to control
   the translation tables, map 4K pages, etc.

I'm fine with the assumptions for an initial support. Did you write-down somewhere those restrictions? So if an issue happen in the future, we will be able to find quickly the issue.

Regards,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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