Re: [Xen-devel] [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
> 
> On 22/05/2018 22:00, Stefano Stabellini wrote:
> > On Tue, 22 May 2018, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > > > This is a reference tiny kconfig for Renesas RCar.  In terms of
> > > > schedulers, it selects credit and NULL only.  It enables all the ARM64
> > > > errata.
> > > 
> > > It still does not feel right that you select only credit and NULL. Why not
> > > credit2 and NULL? Or other combination.
> > 
> > We have to pick a combination of options for certifications and this is
> > the one I am proposing: we need the null scheduler for latency sensitive
> > mission critical VMs and we need credit (the default today) for the
> > others.
> > 
> > I am happy to discuss the pros and cons of other combinations.
> 
> The .config is very subjective and I don't think we can possible cater
> everyone here. For instance, someone might want a different .config for that
> board with credit2... If someone ask for adding this option, what would you
> answer to them? You can't turn them down because this .config is for
> certification.
> 
> But I don't think your solution is the right way to go. See more below for
> some suggestion.
> 
> > 
> >   
> > > > Signed-off-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > > > CC: artem_mygaiev@xxxxxxxx
> > > > CC: volodymyr_babchuk@xxxxxxxx
> > > > 
> > > > ---
> > > > 
> > > > This patch is untested on Renesas RCar, please test!
> > > > Also, I am not sure whether some of the errata workarounds can be
> > > > disabled on the RCar.
> > > > 
> > > > Changes in v2:
> > > > - rename to rcar3
> > > > - only add required symbols, let the defauls take care of the rest
> > > 
> > > I am not sure what you mean here. Your .config below seems contains all
> > > the
> > > options including the non-selected one.
> > > 
> > > Also, this still not solving the problem raised by Andrew regarding keep
> > > them
> > > updated.
> > 
> > It does not have all the options: it only contains the non-default
> > options as per Juergen's suggestion:
> > 
> > https://marc.info/?l=xen-devel&m=152419926530183
> 
> Are you sure? For instance, CONFIG_ACPI is turned off by default but still
> present in the .config. Maybe I am missing something.

That was my mistake.  The process of removing everything but the
non-default options was manual, I might have missed a couple of other
things. I don't know if there is a better way.


> > > It might be easier to maintain if we provide a per platform config option
> > > (e.g
> > > CONFIG_RCAR3) that will select driver for that specific board.
> > > 
> > > The user is then free to select other components (e.g scheduler...). So
> > > you
> > > don't impose memaccess disabled, NULL scheduler...
> > > 
> > > (Thank you Andrii for the suggestion!)
> > 
> > This is a good idea, it would be great to have CONFIG_RCAR3, but it does
> > not take away the need for this kconfig. CONFIG_RCAR3 and rcar3.config
> > are orthogonal, let me explain.
> > 
> > Let's say that we have a CONFIG_RCAR3 that selects everything needed for
> > the Rcar3, such as:
> > 
> > NR_CPUS, SCIF
> > 
> > and deselects:
> > 
> > ACPI, GICV3, the other UARTs, ARM_SMMU.
> > 
> > We still need a reference kconfig with other not platform specific
> > options, for instance:
> > 
> > SCHED_NULL
> > 
> > For two reasons:
> > 1) we need a reference kconfig for certifications, it has to include the
> >     choice of schedulers, debug options, etc, which are not Rcar3 specific
> 
> As you said it is not Rcar3 specific. So this would have to be duplicated on
> each .config (QEMU...).
> 
> It really feels like we want some sort of partial .config (similar to what
> Linux has [1]) that will select non-specific platform option. We could have a
> tiny one, certifiable, "all", server...

Uhm... This is a good suggestion! Following on this line of thinking, is
the idea that the user would:

1) cp configs/certifiable.config .config
2) make olddefconfig # this set to default any missing options
3) make menuconfig -> enable CONFIG_RCAR3
4) make

?

This way, tiny.config doesn't have to have all options, only the
non-default. CONFIG_RCAR3 takes care of enabling the platform specific
stuff.

This could actually work :-)


> > 2) as per previous discussions, we need a set of pre-canned kconfigs to
> >     establish what we security support
> > 
> > rcar3.config is meant to address these two points. CONFIG_RCAR3 would
> > not take away the need for rcar3.config, but it would make rcar3.config
> > shorter and easier to maintain.
> > 
> > CONFIG_RCAR3 was not on my roadmap but I'll see what I can do. Maybe it
> > is best if I do the work for QEMU only (both CONFIG_QEMU and
> > qemu.config) and leave the Renesas work (both CONFIG_RCAR3 and
> > rcar3.config) to EPAM. I cannot test it anyway.
> > 
> 
> Cheers,
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/configs

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