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

Re: [Minios-devel] [UNIKRAFT PATCHv4 21/43] plat/kvm: Add Arm64 basic entry code

On 19/07/18 08:41, Wei Chen wrote:
Hi Julien,

Hi Wei,

-----Original Message-----
From: Julien Grall <julien.grall@xxxxxxx>
Sent: 2018年7月18日 18:46
To: Wei Chen <Wei.Chen@xxxxxxx>; minios-devel@xxxxxxxxxxxxxxxxxxxx;
Cc: Kaly Xin <Kaly.Xin@xxxxxxx>; nd <nd@xxxxxxx>
Subject: Re: [Minios-devel] [UNIKRAFT PATCHv4 21/43] plat/kvm: Add Arm64 basic
entry code

On 18/07/18 08:25, Wei Chen wrote:
Hi Julien,

Hi Wei,

-----Original Message-----
But then why using that for QEMU? You need to compile your ELF assuming

Can I ask you why QEMU supports elf format image? If QEMU support it, why
can't use it? While I was implementing the Arm64 enablement, elf format is
the simplest way for me to verify my code. I just need to place my code at
the entry point, then QEMU would help to load it to CPU reset entry.

Mostly likely because it was support on x86 and was easy to add support
for Arm.

But as I said earlier, I am not against using ELF. However, there need
to be some documentation telling you how to boot. At the moment, it is
close to zero. So can you write down the expectation?

I think I can write down expectation in another improvement patch series,
but not this series. While I was writing this basic entry code, I didn't
think so much. I just wanted Unikraft to be enabled on Arm64 ASAP, even
this code contains some bugs. Let's open another separate thread and patch
series to improve it.

It will be hard for me to review boot code without knowing the
expectations. To be honest, I think it will be very close to the Image
boot process. Unless you provide one for ELF, I will base my review on
the Image boot process.

Ok. It's also a little hard for me to give you detailed expectation state,
because I hadn't think it before. But I will try to give it to you:
1. When I was writing this code, I just assumed I was developing on a
    Cotext-a53 based board.
2. Like most SoC, I think the "virt" also has default implemented register
    value. So I assumed the MMU is off, I/D cache is bypassed.
3. I assumed the "virt" only has EL0/EL1. And when CPU reset, the default
    EL is 1.
4. About the code, I considered it was the combination of bootloader and OS.
    There is not any bootloader like uboot or grub to load my image. The entry
    of my image is the first instruction that will be loaded to PC on CPU reset.
5. I want to enable the MMU to control the memory attributes. Just like add
    readonly for text section, add nx for data, bss or any writeable memory.
6. We don't want users to use the memory as they are using the same memory
    address of physical memory. So I want to create a VA = PA static page-table.

I think above is all I had considered while I was writing this code.

Thank you for writing the expectations, that's actually a good start. A couple of more questions: - Do you have anything that will be passed in the registers? For instance in the case of Image, you have the the DTB address passed in x0. - What is the state of the memory at that time? You probably want to follow what Image says: "The address range corresponding to the loaded kernel image must be cleaned to PoC".


Julien Grall

Minios-devel mailing list



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