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

[Juergen Gross <jgross@xxxxxxxx>]

On 26/04/18 17:00, Jan Beulich wrote:
>>>> 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.

This parameter is defined in arch/x86/acpi/cpufreq/cpufreq.c

You might be right for the conceptual part, but the parameter is
just defined on x86 only.

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

I searched for the parameter definitions and did the annotations
according to their actual scope.

Doing otherwise would be just a lie.


Juergen

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