Re: [PATCH] arm/entry: set x0 before cache maintenance.

[Julien Grall <julien@xxxxxxx>]

On 02/02/2021 02:51, Jianyong Wu wrote:
> Hi Julien,
Hi,


> > -----Original Message-----
> > > > Unrelated to this patch, I am a bit confused with the code. The
> > > > comment on top of __libkvmplat_entry suggests that the DTB in x0, so
> > > > this implies the DTB can be dynamic.
> > > I don't think the dtb address can be dynamic. The   __libkvmplat_entry is a
> > "C" function and the "_dtb" will be its parameter.
> > > Maybe we can use "const" to bond the parameter of __libkvmplat_entry.
> > Does that do your trick?
> >
> > I couldn't find the caller to _libkvmplat_entry. Would you mind to give a
> > pointer to the code calling it?
> Sorry to have mistaken _libkvmplat_entry to _libkvmplat_start. The _libkvmplat_start is a 
> "C" function, and _libkvmplat_entry is entry code with no caller.
>
> > > > However, this line will load the DTB from the image. Can you clarify
> > > > the expected behavior?
> > > This load ops only pass the dtb address to the __libkvmplat_entry.  And I'm
> > not sure why it's not clear about that. Can you give more info?
> >
> > On a Linux setup, the device-tree is most of the time not embedded in the
> > kernel. Instead, it is provided by the firmware (or possibly the toolstack in a
> > virtualized environment).
> >
> > In those setup, the device tree physical address will be provided in x0.
> >
> > _libkvmplat_entry has the following comment on top:
> >
> > /*
> >    * The registers used by _libkvmplat_start:
> >    * x0 - FDT pointer
> >    */
> >
> > So I thought you were following the same behavior as Linux. But from what
> > you wrote, the DTB will instead be embeded in Unikraft. Is that correct?
> In unikraft, DTB is provided by hypervisor like qemu. Qemu/virt puts the DTB at 
> 1G of physical address in guest.
> The "_dtb" is initialized in link script as 1G. In the _libkvmplat_entry,
> we treat _dtb as both the beginning of the normal memory in unikraft and the 
> start address where stores DTB.
> Maybe that confused you. 
Ah! So the DTB will always be loaded at the same place in your case. Now 
it makes sense, thanks for the explanation!
> So I can offer another symbol to represents the beginning of the normal memory 
> to distinguish with _dtb.
> Then we will only use the "_dtb" as the parameter of _libkvmplat_start.
This would be great.

Cheers,

--
Julien Grall