From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>,
"Daniel P. Smith" <dpsmith@apertussolutions.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 1/2] x86/time: introduce command line option to select wallclock
Date: Thu, 12 Sep 2024 15:59:27 +0200 [thread overview]
Message-ID: <ZuLzv2a5pp5yFNmc@mail-itl> (raw)
In-Reply-To: <ZuLxCXuxFbJq-rK_@macbook.local>
[-- Attachment #1: Type: text/plain, Size: 5269 bytes --]
On Thu, Sep 12, 2024 at 03:47:53PM +0200, Roger Pau Monné wrote:
> On Thu, Sep 12, 2024 at 03:30:29PM +0200, Marek Marczykowski-Górecki wrote:
> > On Thu, Sep 12, 2024 at 02:56:55PM +0200, Roger Pau Monné wrote:
> > > On Thu, Sep 12, 2024 at 01:57:00PM +0200, Jan Beulich wrote:
> > > > On 12.09.2024 13:15, Roger Pau Monne wrote:
> > > > > --- a/xen/arch/x86/time.c
> > > > > +++ b/xen/arch/x86/time.c
> > > > > @@ -1552,6 +1552,35 @@ static const char *__init wallclock_type_to_string(void)
> > > > > return "";
> > > > > }
> > > > >
> > > > > +static int __init cf_check parse_wallclock(const char *arg)
> > > > > +{
> > > > > + if ( !arg )
> > > > > + return -EINVAL;
> > > > > +
> > > > > + if ( !strcmp("auto", arg) )
> > > > > + wallclock_source = WALLCLOCK_UNSET;
> > > > > + else if ( !strcmp("xen", arg) )
> > > > > + {
> > > > > + if ( !xen_guest )
> > > > > + return -EINVAL;
> > > > > +
> > > > > + wallclock_source = WALLCLOCK_XEN;
> > > > > + }
> > > > > + else if ( !strcmp("cmos", arg) )
> > > > > + wallclock_source = WALLCLOCK_CMOS;
> > > > > + else if ( !strcmp("efi", arg) )
> > > > > + /*
> > > > > + * Checking if run-time services are available must be done after
> > > > > + * command line parsing.
> > > > > + */
> > > > > + wallclock_source = WALLCLOCK_EFI;
> > > > > + else
> > > > > + return -EINVAL;
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +custom_param("wallclock", parse_wallclock);
> > > > > +
> > > > > static void __init probe_wallclock(void)
> > > > > {
> > > > > ASSERT(wallclock_source == WALLCLOCK_UNSET);
> > > > > @@ -2527,7 +2556,15 @@ int __init init_xen_time(void)
> > > > >
> > > > > open_softirq(TIME_CALIBRATE_SOFTIRQ, local_time_calibration);
> > > > >
> > > > > - probe_wallclock();
> > > > > + /*
> > > > > + * EFI run time services can be disabled from the command line, hence the
> > > > > + * check for them cannot be done as part of the wallclock option parsing.
> > > > > + */
> > > > > + if ( wallclock_source == WALLCLOCK_EFI && !efi_enabled(EFI_RS) )
> > > > > + wallclock_source = WALLCLOCK_UNSET;
> > > > > +
> > > > > + if ( wallclock_source == WALLCLOCK_UNSET )
> > > > > + probe_wallclock();
> > > >
> > > > I don't want to stand in the way, and I can live with this form, so I'd like to
> > > > ask that EFI folks or Andrew provide the necessary A-b / R-b. I'd like to note
> > > > though that there continue to be quirks here. They may not be affecting the
> > > > overall result as long as we have only three possible wallclocks, but there
> > > > might be problems if a 4th one appeared.
> > > >
> > > > With the EFI_RS check in the command line handler and assuming the default case
> > > > of no "efi=no-rs" on the command line, EFI_RS may still end up being off by the
> > > > time the command line is being parsed. With "wallclock=cmos wallclock=efi" this
> > > > would result in no probing and "cmos" chosen if there was that check in place.
> > > > With the logic as added here there will be probing in that case. Replace "cmos"
> > > > by a hypothetical non-default 4th wallclock type (i.e. probing picking "cmos"),
> > > > and I expect you can see how the result would then not necessarily be as
> > > > expected.
> > >
> > > My expectation would be that if "wallclock=cmos wallclock=efi" is used
> > > the last option overrides any previous one, and hence if that last
> > > option is not valid the logic will fallback to the default selection
> > > (in this case to probing).
> >
> > That would be my expectation too. If some kind of preference would be
> > expected, it should looks like wallclock=efi,cmos, but I don't think we
> > need that.
> >
> > > Thinking about this, it might make sense to unconditionally set
> > > wallclock_source = WALLCLOCK_UNSET at the start of parse_wallclock()
> > > to avoid previous instances carrying over if later ones are not valid.
> >
> > This may be a good idea. But more importantly, the behavior should be
> > included in the option documentation (that if a selected value is not
> > available, it fallback to auto). And maybe a log message when that
> > happens (but I'm okay with skipping this one, as selected wallclock
> > source is logged already)?
>
> Thanks, would you be fine with:
>
> ### wallclock (x86)
> > `= auto | xen | cmos | efi`
>
> > Default: `auto`
>
> Allow forcing the usage of a specific wallclock source.
>
> * `auto` let the hypervisor select the clocksource based on internal
> heuristics.
>
> * `xen` force usage of the Xen shared_info wallclock when booted as a Xen
> guest. This option is only available if the hypervisor was compiled with
> `CONFIG_XEN_GUEST` enabled.
>
> * `cmos` force usage of the CMOS RTC wallclock.
>
> * `efi` force usage of the EFI_GET_TIME run-time method when booted from EFI
> firmware.
>
> If the selected option is not available Xen will default to `auto`.
Looks good.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2024-09-12 13:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-12 11:15 [PATCH v6 0/2] x86/time: improvements to wallclock logic Roger Pau Monne
2024-09-12 11:15 ` [PATCH v6 1/2] x86/time: introduce command line option to select wallclock Roger Pau Monne
2024-09-12 11:57 ` Jan Beulich
2024-09-12 12:56 ` Roger Pau Monné
2024-09-12 13:30 ` Marek Marczykowski-Górecki
2024-09-12 13:47 ` Roger Pau Monné
2024-09-12 13:59 ` Marek Marczykowski-Górecki [this message]
2024-09-12 11:15 ` [PATCH v6 2/2] x86/time: prefer CMOS over EFI_GET_TIME Roger Pau Monne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZuLzv2a5pp5yFNmc@mail-itl \
--to=marmarek@invisiblethingslab.com \
--cc=andrew.cooper3@citrix.com \
--cc=dpsmith@apertussolutions.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.