[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Minios-devel] Some considerations of ARM Unikraft supports
Hi,
On 02/02/18 09:10, Wei Chen wrote:
This week I am trying to boot Unikraft on ARM64/KVM platform. In this progress
I have
got some considerations and written a simple proposal:
My first target is to enable Unikraft on ARM64+Kvm, so this proposal would
focus on ARM64+Kvm.
But the goal of ARM support is to enable Unikraft on ARM32/ARM64 based
hypervisors (ARM32/64 Kvm,
ARM64 Xen and etc). So we have to consider to keep current multi-arch framework
and reuse common
code like virtual drivers for ARM32/ARM64.
1. Modify the folders for multi-architectures
1.1. Add arm64 folder to unikraft/arch:
unikraft----arch----arm
|-----x86_64
|-----arm64 <-- New
Above folders contains architecture specified Makefile, Config,
Compiler flags and some
code. In most cases, these files are exclusive. So we'd better keep
each arcitecture in
a standalone floder. This also can avoid doing to much changes to
Unikraft Makefile.
If we add arm64 to unikraft/arch/arm, we have to do more ARCH
comparasion in Makefile:
unikraft----arch----arm----arm32
| |-----arm64 <-- New
|
|-----x86_64
Before:$(UK_BASE)/arch/$(ARCH)/Makefile.uk.
After:$(UK_BASE)/arch/arm/$(ARCH)/Makefile.uk
This change is complex, so we'd better to add arm64 folder to
unikraft/arch.
Except the assembly code, most of the C code should be very similar
between ARM64 and ARM32. So it might make more sense to have a directory
arch/arm with sub-folder arm32 and arm64.
1.2. Add arm64 to unikraft/include/uk/arch
1.3. Add arm64 kvm platform code to unikraft/plat/kvm/arm, and use
Makefile to select
objects for correct architecutre:
ifeq ($(ARCH_X86_64),y)
LIBKVMPLAT_SRCS-y += $(LIBKVMPLAT_BASE)/x86/entry64.S
LIBKVMPLAT_SRCS-y += $(LIBKVMPLAT_BASE)/x86/cpu_x86_64.c
else ifeq ($(ARCH_ARM_64),y)
LIBKVMPLAT_SRCS-y += $(LIBKVMPLAT_BASE)/arm/entry64.S
LIBKVMPLAT_SRCS-y += $(LIBKVMPLAT_BASE)/arm/cpu_arm64.c
else ifeq ($(ARCH_ARM_64),y)
LIBKVMPLAT_SRCS-y += $(LIBKVMPLAT_BASE)/arm/entry.S
LIBKVMPLAT_SRCS-y += $(LIBKVMPLAT_BASE)/arm/cpu_arm.c
endif
1.4. Add a "drivers" folder to unikraft/
This because we may have some virtual device drivers can be shared
among platforms.
For example, we can reuse virtual uart, timer and gic drivers from
arm32/arm64 Kvm/xen.
2. Bootloader
2.1. Because of the BIOS, x86 is using multiboot to load kernel on
Linux-KVM QEMU. But on ARM platforms,
we can skip the EFI and boot from the Virtual Machine's RAM base
address. So we can place _libkvmplat_entry
to the CPU's reset entry by link script. On ARM64 platform, the
default virtual machine CPU model is cortex A15.
Cortex A15 does not support 64-bit. So how come it is the default
virtual machine CPU model for ARM64?
But likely, you want to expose the same MIDR as the underlying CPU. So
if an errata has to be implemented in Unikraft, it will be able to know it.
plat/kvm/arm/link64.ld:
ENTRY(_libkvmplat_entry)
SECTIONS {
. = 0x40000000;
/* Code */
_stext = .;
.text :
{
*(.text)
*(.text.*)
}
_etext = .;
...
}
2.2. Use the fixed physical addresses of PL011 uart, timer and GIC. So we
can skip the device tree parse.
What does promise you the PL011, timer, GIC will always be at the same
address? Or do you expect the user to hack unikraft build system to set
the address?
At least from Xen PoV, the memory layout is not part of the ABI and a
guest should rely on the DT for getting the correct addresses.
2.3. Setup exception traps.
3. Support single CPU.
4. Support multiple threads.
4.1. Implement GIC interrupt controller drivers. If we doesn't specify the
gic version in QEMU's parameter,
default GIC will be detected by kvm_arm_vgic_probe. Most ARM hosts
are using GICv2, GICv3 and GICv4,
and QEMU will provide GICv2 and GICv3 emulators. For best
compatibility, we have to implement gicv2
and gicv3 drivers without MSI/MSI-X support. This means we don't need
to implement gicv2m, gicv3-its
for Unikraft in this time.
4.2. Implment ARMv8 virtual timer driver.
5. Setup a 1:1 mapping pagetable for Physical memory and Virtual memory.
5.1. Configure MMU
5.2. Create page tables with 1GB or 2MB block
6. Implement PSCI interface to support machine shutdown.
FWIW, system_off only exist from PSCI 0.2 and onwards.
7. Network, block and etc IO devices?
Should we have to port virtual device driver like virtio-net, pv-net from
KVM and Xen?
There are no emulation provided on Xen, so you would need PV drivers to
get access to the network/block.
Cheers,
--
Julien Grall
_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel
|
