Re: [Minios-devel] Some considerations of ARM Unikraft supports

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 05/02/18 16:33, Simon Kuenzer wrote:
> On 05.02.2018 11:20, Julien Grall wrote:
> > On 05/02/18 07:22, Wei Chen wrote:
> > > > Or do you expect the user to hack unikraft build system to set
> > > > the address?
> > > For my opinion, Yes. Why should we need to parse the device tree to 
> > > increase our boot
> > > time and footprint?
> > At the moment, you only consider use QEMU mach virt when booting 
> > unikraft on KVM. But someone may decide to use KVM tools, which means 
> > a potential a new memory map. Other may have there custom monitor...
> This is a good point. Actually, I would consider other KVM tools (like 
> kvm-tool, ukvm) as a separate platform. It should be possible to create 
> images for all of those platforms with a single build command. ukvm need 
> to be handled anyways quiet specially.
I am not fully convinced you could assume the memory layout will never 
change between versions.
This is at least the case for Xen, the memory layout is not part of the 
ABI. A guest OS should only rely on Device-Tree. If the guest decides to 
use hardcoded value, then it may break on a newer version of Xen.
Therefore, you would need to provide a new platform for each version. I 
don't think this is very sustainable for Unikraft given that numerous 
possible layout.
> It is possible that we would need to move some code from the platform's 
> folder and move it to a "plat/common" (e.g., "plat/common/arm") folder 
> since it might be shared by some platforms. For now I would simplify it 
> and focus on QEMU. But this is for sure something we need to keep in mind.
> > Furthermore, you may have different memory model depending on whether 
> > you use GICv3/GICv2 or the version of the tools... You may end up with 
> > a lot of different memory map.
> >  From a user perspective this looks like a real burden, for which win? 
> > Saving less than 1K of memory and a few ms in boot.
> I would as many as possible forward decisions to the user. One might be 
> concerned about fewer ms boot time (e.g., reactive VMs that handle a 
> network request on the fly and disappear afterwards), another might not 
> be. Both have their reasons but Unikraft should be a SDK for both use 
> cases.
To be honest, I think this is nothing compare to the time you take to 
create a VM.
Cheers,

--
Julien Grall

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