|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3 7/7] x86/time: probe the CMOS RTC by default
On 03.09.2024 15:03, Roger Pau Monne wrote:
> Probing for the CMOS RTC registers consist in reading IO ports, and we expect
> those reads to have no side effects even when the CMOS RTC is not present.
But what do we gain from this besides possible being slower to boot?
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -326,11 +326,14 @@ Interrupts. Specifying zero disables CMCI handling.
> ### cmos-rtc-probe (x86)
> > `= <boolean>`
>
> -> Default: `false`
> +> Default: `true`
>
> Flag to indicate whether to probe for a CMOS Real Time Clock irrespective of
> ACPI indicating none to be there.
>
> +**WARNING: The `cmos-rtc-probe` option is deprecated and superseded by
> +_wallclock=no-cmos-probe_ using both options in combination is undefined.**
Hmm, but then ...
> @@ -2822,7 +2825,7 @@ suboptimal scheduling decisions, but only when the
> system is
> oversubscribed (i.e., in total there are more vCPUs than pCPUs).
>
> ### wallclock (x86)
> -> `= auto | xen | cmos | efi`
> +> `= auto | xen | cmos | no-cmos-probe | efi`
... this wants to be a boolean sub-option "cmos-probe", such that the flag
can still be set both ways (in particular for a later command line option
to override an earlier one).
> @@ -2836,6 +2839,11 @@ Allow forcing the usage of a specific wallclock source.
>
> * `cmos` force usage of the CMOS RTC wallclock.
>
> + * `no-cmos-probe` do not probe for the CMOS RTC presence if the ACPI FADT
> + table signals there's no CMOS RTC. Implies using the same heuristics as
> + the `auto` option. By default Xen will probe for the CMOS RTC presence
> + even when ACPI FADT signals no CMOS RTC available.
"By default ..." reads as if this would always occur, which I don't think
is the case.
> @@ -1560,6 +1560,8 @@ static int __init cf_check parse_wallclock(const char
> *arg)
> if ( !arg )
> return -EINVAL;
>
> + cmos_rtc_probe = true;
> +
> if ( !strcmp("auto", arg) )
> wallclock_source = WALLCLOCK_UNSET;
> else if ( !strcmp("xen", arg) )
> @@ -1571,6 +1573,8 @@ static int __init cf_check parse_wallclock(const char
> *arg)
> }
> else if ( !strcmp("cmos", arg) )
> wallclock_source = WALLCLOCK_CMOS;
> + else if ( !strcmp("no-cmos-probe", arg) )
> + cmos_rtc_probe = false;
> else if ( !strcmp("efi", arg) )
> {
> if ( !efi_enabled(EFI_RS) )
And to request a particular wallclock _and_ control the probing one then
needs two wallclock= on the command line? And - because of the forcing to
true of cmos_rtc_probe - even in a particular order. Not very nice from a
usability pov.
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |