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

[Julien Grall <julien.grall@xxxxxxx>]

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;
> > simon.kuenzer@xxxxxxxxx
> > 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
> > I
> > > > > 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".
Cheers,

--
Julien Grall

_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel