| 
    
 [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  |