On Fri, 1 Jun 2018, Julien Grall wrote:
> Hi,
> Sorry for the formatting. I am pretty sure you need to CC "THE REST" here.
>
> On Thu, 31 May 2018, 22:50 Stefano Stabellini, <sstabell...@kernel.org> wrote:
> Add specific per-platform defaults for NR_CPUS. Note that the order of
> the defaults matter: they need to go first, otherwise the generic
> defaults will be applied.
>
> This is done so that Xen builds customized for a specific hardware
> platform can have the right NR_CPUS number.
>
> Signed-off-by: Stefano Stabellini <sstabell...@kernel.org>
> CC: jbeul...@suse.com
> CC: andrew.coop...@citrix.com
> ---
> xen/arch/Kconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig
> index cf0acb7..d451eb8 100644
> --- a/xen/arch/Kconfig
> +++ b/xen/arch/Kconfig
> @@ -2,6 +2,9 @@
> config NR_CPUS
> int "Maximum number of physical CPUs"
> range 1 4095
> + default "8" if ARM && RCAR3
> + default "4" if ARM && QEMU
> + default "4" if ARM && MPSOC
> default "256" if X86
> default "128" if ARM
> ---help---
>
>
> But I am not sure how this will work as with this series you can select
> multiple platforms in on Kconfig. What will be the end
> result?
The end result is the first default that applies. In this case, if
RCAR3, QEMU and MPSOC are all selected, then NR_CPUS would be set to
8, which is actually what one would want if she is trying to build Xen
for these three platforms, but it is not what one would want if she was
trying to build a generic Xen config for distros.
This is not great.
The option list you suggested could help solve the NR_CPUS issue, see
below.
> Anyway, as I mention the way to go is a option list with only one possible
> choice.
I am OK with an option list, the issue that we cannot have an ALL option
in the list that selects the other options as I wrote previously. For
instance, the following is NOT allowed:
config ALL
bool "All Platforms"
select MPSOC
However, having CONFIG_ALL would solve the NR_CPUS problem because we
could do:
config NR_CPUS
default "128" if ARM && ALL
default "8" if ARM && RCAR3
default "4" if ARM && QEMU
default "4" if ARM && MPSOC
default "128" if ARM
Which would give us exactly the default we want for NR_CPUS.
So I agree that we should turn platform support into an option list and
we should also add an ALL option to solve the NR_CPUS problem.
If we do that, the remaining problem is how to implement ALL. I found a
workaround for the kconfig issue described above. The following works
correctly:
choice
prompt "Platform Support"
default ALL
---help---
Choose Xen support for different hardware platforms.
config ALL
bool "All Platforms"
select MPSOC_PLATFORM
select QEMU_PLATFORM
select RCAR3_PLATFORM
---help---
Enable support for all platforms.
config QEMU
bool "QEMU aarch virt machine support"
depends on ARM_64
select QEMU_PLATFORM
---help---
Enable all the required drivers for QEMU aarch64 virt emulated
machine.
config RCAR3
bool "Renesas RCar3 support"
depends on ARM_64
select RCAR3_PLATFORM
---help---
Enable all the required drivers for Renesas RCar3
config MPSOC
bool "Xilinx Ultrascale+ MPSoC support"
depends on ARM_64
select MPSOC_PLATFORM
---help---
Enable all the required drivers for Xilinx Ultrascale+ MPSoC
endchoice
config QEMU_PLATFORM
bool
select GICV3
select HAS_PL011
config RCAR3_PLATFORM
bool
select HAS_SCIF
config MPSOC_PLATFORM
bool
select HAS_CADENCE_UART
select ARM_SMMU
This looks like the best way forward and would solve all issues._______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
