Hi Marco,
On 04/03/2022 17:46, Marco Solieri wrote:
> From: Luca Miccio <lucmiccio@gmail.com>
>
> Four additional parameters in the Xen command line are used to define
> the underlying coloring policy, which is not directly configurable
> otherwise.
>
> Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
> Signed-off-by: Marco Solieri <marco.solieri@minervasys.tech>
> ---
> docs/misc/xen-command-line.pandoc | 51 +++++++++++++++++++++++++++++--
> 1 file changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index efda335652..a472d51cf9 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -299,6 +299,20 @@ can be maintained with the pv-shim mechanism.
> cause Xen not to use Indirect Branch Tracking even when support is
> available in hardware.
>
> +### buddy\_size (arm64)
> +> `= <size in megabyte>`
> +
> +> Default: `64 MB`
> +
> +Amount of memory reserved for the buddy allocator when colored allocator is
> +active. This options is useful only if coloring support is enabled.
> +The colored allocator is meant as an alternative to the buddy allocator,
> +since its allocation policy is by definition incompatible with the
> +generic one. Since the Xen heap systems is not colored yet, we need to
> +support the coexistence of the two allocators for now. This parameter, which is
> +optional and for expert only, is used to set the amount of memory reserved to
> +the buddy allocator.
A few questions:
- How did you chose the default?
- How can a user decide the size of the buddy_size?
> +
> ### clocksource (x86)
> > `= pit | hpet | acpi | tsc`
>
> @@ -884,7 +898,17 @@ Controls for the dom0 IOMMU setup.
>
> Incorrect use of this option may result in a malfunctioning system.
>
> -### dom0_ioports_disable (x86)
This change sounds unrelated to the patch itself. I would also expect
that we would want to backport it. So can this be backported.
> +### dom0\_colors (arm64)
> +> `= List of <integer>-<integer>`
> +
> +> Default: `All available colors`
> +
> +Specify dom0 color configuration. If the parameter is not set, all available
> +colors are chosen and the user is warned on Xen's serial console. This color
> +configuration acts also as the default one for all DomUs that do not have any
> +explicit color assignment in their configuration file.
> +
> +### dom0\_ioports\_disable (x86)
> > `= List of <hex>-<hex>`
>
> Specify a list of IO ports to be excluded from dom0 access.
> @@ -2625,6 +2649,20 @@ unknown NMIs will still be processed.
> Set the NMI watchdog timeout in seconds. Specifying `0` will turn off
> the watchdog.
>
> +### way\_size (arm64)
> +> `= <size in byte>`
> +
> +> Default: `Obtained from the hardware`
> +
> +Specify the way size of the Last Level Cache. This parameter is only useful with
> +coloring support enabled. It is an optional, expert-only parameter and it is
> +used to calculate what bits in the physical address can be used by the coloring
> +algorithm, and thus the maximum available colors on the platform. It can be
> +obtained by dividing the total LLC size by the number of associativity ways.
> +By default, the value is also automatically computed during coloring
> +initialization to avoid any kind of misconfiguration. For this reason, it is
> +highly recommended to use this boot argument with specific needs only.
Given the last two sentences, why would someone wants to use it?
> +
> ### x2apic (x86)
> > `= <boolean>`
>
> @@ -2642,7 +2680,16 @@ In the case that x2apic is in use, this option switches between physical and
> clustered mode. The default, given no hint from the **FADT**, is cluster
> mode.
>
> -### xenheap_megabytes (arm32)
Same here.
> +### xen\_colors (arm64)
> +> `= List of <integer>-<integer>`
> +
> +> Default: `0-0: the lowermost color`
> +
> +Specify Xen color configuration.
> +Two colors are most likely needed on platforms where private caches are
> +physically indexed, e.g. the L1 instruction cache of the Arm Cortex-A57.
How can someone decide the number of colors to be used for Xen?
Cheers,
--
Julien Grall