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

[Julien Grall <julien.grall@xxxxxxxxxx>]

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

--
Julien Grall

_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel