Re: [Xen-devel] [PATCH 2/7] doc: add architecture qualifier to boot parameter entries

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.04.18 at 08:44, <jgross@xxxxxxxx> wrote:
> Many of the architecture specific boot parameters are not qualified
> as such. Correct that.

I think we want to distinguish between ones really only be meaningful for
some architecture vs ones which are currently only implemented for just
one. For example ...

> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -110,7 +110,7 @@ domain 0 command line
>  Specify which ACPI MADT table to parse for APIC information, if more
>  than one is present.
>  
> -### acpi\_pstate\_strict
> +### acpi\_pstate\_strict (x86)
>  > `= <boolean>`

... I'm no sure P-states are meaningless on ARM. They're certainly a general
ACPI concept, and were similarly used e.g. for IA64.

> @@ -119,12 +119,12 @@ Enforce checking that P-state transitions by the ACPI 
> cpufreq driver
>  actually result in the nominated frequency to be established. A warning
>  message will be logged if that isn't the case.
>  
> -### acpi\_skip\_timer\_override
> +### acpi\_skip\_timer\_override (x86)
>  > `= <boolean>`

This one, otoh, is fine to be named x86 only, as it deals with x86
specific BIOS quirks.

> @@ -199,7 +199,7 @@ to be performed without the overhead of a complete TLB 
> flush.
>  Forces all CPUs' full state to be logged upon certain fatal asynchronous
>  exceptions (watchdog NMIs and unexpected MCEs).
>  
> -### ats
> +### ats (x86)
>  > `= <boolean>`

ATS is a general PCI concept, so I wouldn't want this option to be tagged
x86 only.

Just to give a few examples.

Jan



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