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

[Simon Kuenzer <simon.kuenzer@xxxxxxxxx>]

On 05.02.2018 18:04, Julien Grall wrote:
> 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.
If it is part of ABI, yes I agree, the platform library has to parse the 
device tree - and this should be the default implementation when 
building. Every simplification (like assuming a specific layout), is 
something that should be only activate when a user selects an according 
build option. But it is fine when we add such simplification 
functionality later.
> > 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.
For now, you are right, VM creation times (100s of ms) are huge compared 
to the actual boot time of a Unikernel (10s ms). However, I imagine that 
we will get optimized toolstacks when Unikernels have gained more 
popularity. We had some experiments where we booted an Unikernel when 
the first network package arrive at the hypervisor (e.g., ICMP ping 
request, ARP request or TCP SYN). We forwarded it to the freshly booted 
VM which handled the response. The idea is similar to Jitsu but we used 
our own optimized toolstack (https://github.com/sysml/lightvm). In such 
use case, every ms matter that contributes to the total boot time 
(including VM creation).
> Cheers,
Thanks,

Simon

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