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月5日 18:20
> To: Wei Chen <Wei.Chen@xxxxxxx>; Simon Kuenzer <simon.kuenzer@xxxxxxxxx>
> 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 07:22, Wei Chen wrote:
> > Hi Julien,
> 
> Hi Wei,
> 
> >> -----Original Message-----
> >> But likely, you want to expose the same MIDR as the underlying CPU. So
> >> if an errata has to be implemented in Unikraft, it will be able to know it.
> >>
> >
> > Exposing the underlying CPU's MIDR to guest is depending on the hypervisors.
> > For Unikraft itself, it doesn't know whether this MIDR is the same as the
> underlying
> > CPU or not. And actually, no matter what cpumodel the hypervisor is
> emulating, the
> > code is running on the physical CPU directly. We don't emulate the CPU
> instructions.
> > If we run Unikraft on a corext-a53 host CPU, we can compile this image with
> gcc flags
> > like fix-a53-error.
> 
> Have a look at linux/arch/arm64/kernel/cpu_errata.c, there are quite a
> few errata that needs to know the physical MIDR. So likely you always
> want to expose the physical MIDR and not a custom one.
> 

I feel confused about this comment and I have two questions about this comment:
1. How can I select the expose value of MIDR? The Unikraft code is a binary
   that is running as guest OS? I think how to expose the MIDR is controlled
   by the hypervisors. For Unikraft, the MIDR is read-only.
2. For example, on a cortex-a72 host, we select -cpu cortex-a53 to run Unikraft
   image. Should we implement cortex-a72 errata or cortex-a53 errata in 
Unikraft?

> >>>
> >>>            plat/kvm/arm/link64.ld:
> >>>            ENTRY(_libkvmplat_entry)
> >>>            SECTIONS {
> >>>                . = 0x40000000;
> >>>
> >>>                /* Code */
> >>>                _stext = .;
> >>>
> >>>                .text :
> >>>                {
> >>>                    *(.text)
> >>>                    *(.text.*)
> >>>                }
> >>>
> >>>                _etext = .;
> >>>                ...
> >>>            }
> >>>
> >>>       2.2. Use the fixed physical addresses of PL011 uart, timer and GIC.
> So
> >> we can skip the device tree parse.
> >>
> >> What does promise you the PL011, timer, GIC will always be at the same
> >> address?
> >
> > My original idea was that we selected a fixed machine (mach-virt) for
> Unikraft to run.
> > In this case, the memory map is fixed.
> 
> That's does not answer to my question. What does promise you the memory
> map will never change accross QEMU version?
> 

I admit that you're right, I can't promise the memory map would not be
changed in later versions of QEMU.

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

As Simon had already replied this comment, I would reply my comment in
his mail.

> >
> >> At least from Xen PoV, the memory layout is not part of the ABI and a
> >> guest should rely on the DT for getting the correct addresses.
> >>
> >
> > I understand your concern. It's not a part of the ABI. So the addresses can
> be changed
> > for different boards.
> 
> It is not only about different boards, but also different tools to
> create VM (see above).
> 
> >
> > I think we must do a tradeoff between flexibility and deploy density (boot
> time and footprint)
> 
> I am quite curious to know your requirements here.
> 

These requirements are coming from some telecom carriers. They need to use 
Unikernel 
For Just-in-Time Summoning services. When network request data is coming, they 
will
start a Unikernel to respond such request data. Sometimes, the restriction of 
response
time would be tens of ms. In this case the Unikernel needs boot very fast. At 
the
same time, they have security and high density deploy requirements. So the tiny 
footprint
is also a requirement.


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