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

[Wei Chen <Wei.Chen@xxxxxxx>]

Hi Simon,

> -----Original Message-----
> From: Simon Kuenzer [mailto:simon.kuenzer@xxxxxxxxx]
> Sent: 2018年2月7日 0:12
> To: Wei Chen <Wei.Chen@xxxxxxx>; Julien Grall <julien.grall@xxxxxxxxxx>
> 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
> 
> 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.
> 

Yes, currently we can focus on QEMU : )

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