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

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


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

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