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

[Wei Chen <Wei.Chen@xxxxxxx>]

> -----Original Message-----
> From: Julien Grall <julien.grall@xxxxxxx>
> Sent: 2018年7月19日 21:21
> 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 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.

No. In elf format, the entry code is the first instruction the CPU will load.
Elf loader of QEMU will load the entry code to cpu->pc. The elf loader will
place the DTB at RAM base address, it will not pass this address to 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".

At the very beginning, I assume QEMU had help me sync the image memory to PoU
at least. Because guest will read image bypass the cache.

> 
> Cheers,
> 
> --
> Julien Grall
_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel