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