On 26/04/18 17:00, Jan Beulich wrote:
On 24.04.18 at 08:44, 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)
>> > `= `
>
> ... 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)
>> > `= `
>
> 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)
>> > `= `
>
> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel