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月6日 0:33
> To: Julien Grall <julien.grall@xxxxxxxxxx>; 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
> 
> Hi all,
> 
> On 05.02.2018 11:20, Julien Grall wrote:
> >
> >
> > 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.
> >
> >>>>
> >>>>            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?
> >
> >>
> >>> 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.
> 

Yes, I agree with you, different hypervisor must be consider as a separate
platform. From my side, I don't expect a single Unikraft image can run
on multiple platforms like Linux. I think one image can only run on one
platform is better. This will avoid putting some never used code inside
the Unikraft image.

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

If we don't have "arch/arm folder" for shared arm32/64 code, I agree to move
These codes to "plat/common/arm". If we have "arch/arm" why don't we move them
to this folder?

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

That makes sense.

> >>
> >>> 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.
> >
> > Cheers,
> >
> 
> Thanks,
> 
> Simon
_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel