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

[Simon Kuenzer <simon.kuenzer@xxxxxxxxx>]

Hi Wei,

On 06.02.2018 09:36, Wei Chen wrote:
> 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.
I think QEMU is the de-facto standard deployment for KVM on ARM, right 
(please correct me if I am wrong with this assumption)? This is why we 
should start with this, in order to reach out to as many KVM on ARM 
users as we can and make the usage easy for them. I would lower the 
priority for other platforms, e.g., kvm-tool, or ukvm - as you said.
> > Cheers,
> >
> > --
> > Julien Grall
_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel