All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.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 v5 3/4] x86/time: introduce command line option to select wallclock
Date: Tue, 10 Sep 2024 18:20:03 +0200	[thread overview]
Message-ID: <ZuBxsybr71Sgtx1Y@macbook.local> (raw)
In-Reply-To: <7d55bda8-222a-46c8-a810-79ba5c0928d3@suse.com>

On Tue, Sep 10, 2024 at 04:29:43PM +0200, Jan Beulich wrote:
> On 10.09.2024 16:24, Roger Pau Monné wrote:
> > On Tue, Sep 10, 2024 at 03:49:52PM +0200, Jan Beulich wrote:
> >> On 10.09.2024 15:10, Roger Pau Monné wrote:
> >>>  Would you be fine with
> >>> adding the following in init_xen_time():
> >>>
> >>>     /*
> >>>      * EFI run time services can be disabled form 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();
> >>
> >> ... this is probably the best we can do (nit: s/form/from/ in the comment;
> >> maybe also "..., hence the check done as part of option parsing may not
> >> suffice" or some such).
> > 
> > I didn't put in my previous reply, but I've removed the efi_enabled()
> > check from the option parsing and instead added this comment:
> > 
> >         /*
> >          * Checking if run-time services are available must be done after
> >          * command line parsing.
> >          */
> > 
> > I don't think there's much point in doing the check in
> > parse_wallclock() if it's not reliable, so your reference in the
> > comment to "the check done as part of option parsing" is no longer
> > valid.
> 
> Hmm. Rejecting the option if we can is reasonable imo. "efi=rs" can imo only
> sensibly be used to override an earlier "efi=no-rs". Hence what we see while
> parsing the wallclock option gives us at least reasonable grounds to reject
> the option if EFI_RS is already clear. We then merely fail to reject the
> option if the flag is cleared later.

I won't strongly argue about it, but I think having a non-reliable
check in parse_wallclock() is confusing.  I would have to add a
comment there anyway to note that depending on the position of the efi
and wallclock parameters the check for EFI_RS might not be effective -
at which point I think it's best to unify the check so it's uniformly
performed in init_xen_time().

> Yet in the end I'd be happy to leave this particular aspect to you and the
> EFI maintainers.

Thanks again for the feedback.

Roger.


  reply	other threads:[~2024-09-10 16:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-09 14:54 [PATCH v5 0/4] x86/time: improvements to wallclock logic Roger Pau Monne
2024-09-09 14:54 ` [PATCH v5 1/4] x86/time: pull cmos_rtc_probe outside of function and rename Roger Pau Monne
2024-09-09 15:04   ` Jan Beulich
2024-09-09 14:54 ` [PATCH v5 2/4] x86/time: introduce probing logic for the wallclock Roger Pau Monne
2024-09-10  9:23   ` Jan Beulich
2024-09-09 14:54 ` [PATCH v5 3/4] x86/time: introduce command line option to select wallclock Roger Pau Monne
2024-09-10  9:32   ` Jan Beulich
2024-09-10 13:10     ` Roger Pau Monné
2024-09-10 13:49       ` Jan Beulich
2024-09-10 14:24         ` Roger Pau Monné
2024-09-10 14:29           ` Jan Beulich
2024-09-10 16:20             ` Roger Pau Monné [this message]
2024-09-09 14:54 ` [PATCH v5 4/4] 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=ZuBxsybr71Sgtx1Y@macbook.local \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dpsmith@apertussolutions.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=marmarek@invisiblethingslab.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.