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 <sstabell...@kernel.org>
CC: artem_myga...@epam.com
CC: volodymyr_babc...@epam.com
---
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.
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...
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
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
