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

[Wei Chen <Wei.Chen@xxxxxxx>]

Hi Julien,

> -----Original Message-----
> From: Julien Grall [mailto:julien.grall@xxxxxxxxxx]
> Sent: 2018年2月6日 1:05
> To: Simon Kuenzer <simon.kuenzer@xxxxxxxxx>; Wei Chen <Wei.Chen@xxxxxxx>
> Cc: Felipe Huici <Felipe.Huici@xxxxxxxxx>; Kaly Xin <Kaly.Xin@xxxxxxx>; Shijie
> Huang <Shijie.Huang@xxxxxxx>; Florian Schmidt <Florian.Schmidt@xxxxxxxxx>;
> Costin Lupu <costin.lup@xxxxxxxxx>; nd <nd@xxxxxxx>; minios-
> devel@xxxxxxxxxxxxx
> Subject: Re: [Minios-devel] Some considerations of ARM Unikraft supports
> 
> 
> 
> 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.
> 

I think Simon doesn't assume the memory layout will never be changed between
versions. We just treat kvmtools as another platform. In my earlier reply,
I had be convinced by you to enable DTB for those platforms which need more
Flexibility ; )


> >
> > 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.
> 

You have got the point. I had ignored that QEMU is a generic platform, it's 
unlikely
to be chosen by users to deploy a high customized, tiny, fast boot, high secure
Unikernel. Something like solo5/ukvm would take this role.

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