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

[Simon Kuenzer <simon.kuenzer@xxxxxxxxx>]

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