Re: [RFC PATCH] arm/gicv2: make GICv2 driver and vGICv2 optional

[Luca Fancellu <Luca.Fancellu@xxxxxxx>]

>>>>>> 
>>>>>> - UART enabled -
>>>>>> - Boot CPU booting -
>>>>>> - Current EL 0000000000000008 -
>>>>>> - Initialize CPU -
>>>>>> - Turning on paging -
>>>>>> - Zero BSS -
>>>>>> - Ready -
>>>>>> (XEN) Checking for initrd in /chosen
>>>>>> (XEN) RAM: 0000000080000000 - 00000000feffffff
>>>>>> (XEN) RAM: 0000000880000000 - 00000008ffffffff
>>>>>> (XEN)
>>>>>> (XEN) MODULE[0]: 0000000084000000 - 000000008415d000 Xen
>>>>>> (XEN) MODULE[1]: 00000000fd6c5000 - 00000000fd6c8000 Device Tree
>>>>>> (XEN) MODULE[2]: 0000000080080000 - 00000000814f1a00 Kernel
>>>>>> (XEN)  RESVD[0]: 0000000080000000 - 0000000080010000
>>>>>> (XEN)  RESVD[1]: 0000000018000000 - 00000000187fffff
>>>>>> (XEN)
>>>>>> (XEN)
>>>>>> (XEN) Command line: noreboot dom0_mem=1024M console=dtuart 
>>>>>> dtuart=serial0 bootscrub=0
>>>>>> (XEN) PFN compression on bits 20...22
>>>>>> (XEN) Domain heap initialised
>>>>>> (XEN) Booting using Device Tree
>>>>>> (XEN) Platform: Generic System
>>>>>> (XEN)
>>>>>> (XEN) ****************************************
>>>>>> (XEN) Panic on CPU 0:
>>>>>> (XEN) Unable to find compatible GIC in the device tree
>>>>>> (XEN) ****************************************
>>>>>> (XEN)
>>>>>> (XEN) Manual reset required ('noreboot' specified)

Hi Julien, Michal,

>>>>> Having early printk enabled all the time is not common and not enabled in 
>>>>> release builds FWIK.
>>> 
>>> There are a lot of information printed before the console is properly
>>> brought up. I wonder if we should look at adding early console like
>>> Linux does?
>> I guess it is not a matter of "if" but "when" and I think it's just that no 
>> one has time to do that
>> since it is more a like a feature for developers rather than for customers 
>> (they just report the issue
>> and we need to fix it :)).
> 
> Sure. This is always the case, but it also means developpers will continue to 
> waste time when investigating early boot issues. I wouldn't be surprised if 
> the total time wasted is more than the actual effort to add support :).

I’ve not investigated on the amount of time needed to add that, I wouldn’t 
underestimate that and unfortunately people have
different capacity and companies have different priorities, so a quick feature 
can translate on months when the time allocated
for a particular job is, let’s say, one day a month.

> 
>> There are so many things that can go wrong during early boot including the 
>> entire boofdt parsing
>> and having earlycon would be so desirable.
> It is not clear what to take from your reply. Earlier you were concerned 
> about the error not showing up in the log if the .config is not correct.
> 
> There is no really quick fix for that as a .config may work for platform A 
> but not platform B. The only viable solution is having an early console.
> 
> Anything else like forcing to always have one GICvX selected is just a hack 
> that would work for one set of people but not the others.

I agree with you in part, when you say that it would work for one set of people 
but not the others, isn’t it always the case? We are providing
a defconfig that would fit the majority of the people, but it’s always a set of 
them.

More specific to this patch, with the provided Kconfig “hack” as you say, it is 
not only providing the same user experience as the current state,
it is doing more, it is providing a way to exclude from the build the GICv2 
which is not possible currently, this work aims to provide a more
fine granular configuration so that experienced users can remove entire modules 
that they don’t need in their platform so that they don’t have
to take them into account when going to, for example, safety critical audits.

I agree with you that earlycon would be perfect, so that we could make the user 
remove every module and let him know quickly the issue,
but on the other hand it is a complete new feature that you are requesting (are 
you?) to make this patch go forward.

My personal opinion is that, since this patch is not affecting the user 
experience, it is maintaining the current status (not ideal), but at least
It is providing something more, it would be a shame to throw that in the bin 
because no one has time to work on earlycon.

Cheers,
Luca