netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Peter Hilber <peter.hilber@opensynergy.com>,
	linux-kernel@vger.kernel.org,  virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,  linux-rtc@vger.kernel.org,
	"Ridoux, Julien" <ridouxj@amazon.com>,
	 virtio-dev@lists.linux.dev, "Luu, Ryan" <rluu@amazon.com>
Cc: "Christopher S. Hall" <christopher.s.hall@intel.com>,
	Jason Wang <jasowang@redhat.com>,
	John Stultz <jstultz@google.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	netdev@vger.kernel.org,
	Richard Cochran <richardcochran@gmail.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
	Marc Zyngier <maz@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Alessandro Zummo <a.zummo@towertech.it>,
	 Alexandre Belloni <alexandre.belloni@bootlin.com>
Subject: Re: [RFC PATCH v2] ptp: Add vDSO-style vmclock support
Date: Thu, 27 Jun 2024 17:03:04 +0100	[thread overview]
Message-ID: <51dcda5b675fb68c54b74fd19c408a3a086fc412.camel@infradead.org> (raw)
In-Reply-To: <8d9d7ce2-4dd1-4f54-a468-79ef5970a708@opensynergy.com>

[-- Attachment #1: Type: text/plain, Size: 4848 bytes --]


I've updated the tree at
https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/vmclock
(but not yet the qemu one).

I think I've taken into account all your comments apart from the one
about non-64-bit counters wrapping. I reduced the seq_count to 32 bit
to make room for a 32-bit flags field, added the time type
(UTC/TAI/MONOTONIC) and a smearing hint, with some straw man
definitions for smearing algorithms for which I could actually find
definitions.

The structure now looks like this:


struct vmclock_abi {
	uint32_t magic;
#define VMCLOCK_MAGIC	0x4b4c4356 /* "VCLK" */
	uint16_t size;		/* Size of page containing this structure */
	uint16_t version;	/* 1 */

	/* Sequence lock. Low bit means an update is in progress. */
	uint32_t seq_count;

	uint32_t flags;
	/* Indicates that the tai_offset_sec field is valid */
#define VMCLOCK_FLAG_TAI_OFFSET_VALID		(1 << 0)
	/*
	 * Optionally used to notify guests of pending maintenance events.
	 * A guest may wish to remove itself from service if an event is
	 * coming up. Two flags indicate the rough imminence of the event.
	 */
#define VMCLOCK_FLAG_DISRUPTION_SOON		(1 << 1) /* About a day */
#define VMCLOCK_FLAG_DISRUPTION_IMMINENT	(1 << 2) /* About an hour */
	/* Indicates that the utc_time_maxerror_picosec field is valid */
#define VMCLOCK_FLAG_UTC_MAXERROR_VALID		(1 << 3)
	/* Indicates counter_period_error_rate_frac_sec is valid */
#define VMCLOCK_FLAG_PERIOD_ERROR_VALID		(1 << 4)

	/*
	 * This field changes to another non-repeating value when the CPU
	 * counter is disrupted, for example on live migration. This lets
	 * the guest know that it should discard any calibration it has
	 * performed of the counter against external sources (NTP/PTP/etc.).
	 */
	uint64_t disruption_marker;

	uint8_t clock_status;
#define VMCLOCK_STATUS_UNKNOWN		0
#define VMCLOCK_STATUS_INITIALIZING	1
#define VMCLOCK_STATUS_SYNCHRONIZED	2
#define VMCLOCK_STATUS_FREERUNNING	3
#define VMCLOCK_STATUS_UNRELIABLE	4

	uint8_t counter_id;
#define VMCLOCK_COUNTER_INVALID		0
#define VMCLOCK_COUNTER_X86_TSC		1
#define VMCLOCK_COUNTER_ARM_VCNT	2
#define VMCLOCK_COUNTER_X86_ART		3

	/*
	 * By providing the offset from UTC to TAI, the guest can know both
	 * UTC and TAI reliably, whichever is indicated in the time_type
	 * field. Valid if VMCLOCK_FLAG_TAI_OFFSET_VALID is set in flags.
	 */
	int16_t tai_offset_sec;

	/*
	 * The time exposed through this device is never smeaared; if it
	 * claims to be VMCLOCK_TIME_UTC then it MUST be UTC. This field
	 * provides a hint to the guest operating system, such that *if*
	 * the guest OS wants to provide its users with an alternative
	 * clock which does not follow the POSIX CLOCK_REALTIME standard,
	 * it may do so in a fashion consistent with the other systems
	 * in the nearby environment.
	 */
	uint8_t leap_second_smearing_hint;
	/* Provide true UTC to users, unsmeared. */;
#define VMCLOCK_SMEARING_NONE			0
	/*
	 * https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/
	 * From noon on the day before to noon on the day after, smear the
	 * clock by a linear 1/86400s per second.
	*/
#define VMCLOCK_SMEARING_LINEAR_86400		1
	/*
	 * draft-kuhn-leapsecond-00
	 * For the 1000s leading up to the leap second, smear the clock by
	 * clock by a linear 1ms per second.
	 */
#define VMCLOCK_SMEARING_UTC_SLS		2

	/*
	 * What time is exposed in the time_sec/time_frac_sec fields?
	 */
	uint8_t time_type;
#define VMCLOCK_TIME_UNKNOWN		0	/* Invalid / no time exposed */
#define VMCLOCK_TIME_UTC		1	/* Since 1970-01-01 00:00:00z */
#define VMCLOCK_TIME_TAI		2	/* Since 1970-01-01 00:00:00z */
#define VMCLOCK_TIME_MONOTONIC		3	/* Since undefined epoch */

	/* Bit shift for counter_period_frac_sec and its error rate */
	uint8_t counter_period_shift;

	/*
	 * Unlike in NTP, this can indicate a leap second in the past. This
	 * is needed to allow guests to derive an imprecise clock with
	 * smeared leap seconds for themselves, as some modes of smearing
	 * need the adjustments to continue even after the moment at which
	 * the leap second should have occurred.
	 */
	int8_t leapsecond_direction;
	uint64_t leapsecond_tai_sec; /* Since 1970-01-01 00:00:00z */

	/*
	 * Paired values of counter and UTC at a given point in time.
	 */
	uint64_t counter_value;
	uint64_t time_sec; /* Since 1970-01-01 00:00:00z */
	uint64_t time_frac_sec;

	/*
	 * Counter frequency, and error margin. The unit of these fields is
	 * seconds >> (64 + counter_period_shift)
	 */
	uint64_t counter_period_frac_sec;
	uint64_t counter_period_error_rate_frac_sec;

	/* Error margin of UTC reading above (± picoseconds) */
	uint64_t utc_time_maxerror_picosec;
};

#endif /*  __VMCLOCK_H__ */


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]

  parent reply	other threads:[~2024-06-27 16:03 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-18  7:38 [RFC PATCH v3 0/7] Add virtio_rtc module and related changes Peter Hilber
2023-12-18  7:38 ` [RFC PATCH v3 4/7] virtio_rtc: Add module and driver core Peter Hilber
2023-12-18  7:38 ` [RFC PATCH v3 5/7] virtio_rtc: Add PTP clocks Peter Hilber
2024-06-15  8:01   ` David Woodhouse
2024-06-20 12:01     ` Peter Hilber
2024-06-20 14:33       ` David Woodhouse
2024-03-07 14:02 ` [RFC PATCH v3 0/7] Add virtio_rtc module and related changes David Woodhouse
2024-03-08 10:32   ` Peter Hilber
2024-03-08 12:33     ` David Woodhouse
2024-03-11 18:24       ` Peter Hilber
2024-03-12 17:15         ` David Woodhouse
2024-03-13  9:45           ` Peter Hilber
2024-03-13 11:18             ` Alexandre Belloni
2024-03-13 12:29               ` David Woodhouse
2024-03-13 12:58                 ` Alexandre Belloni
2024-03-13 14:06                   ` David Woodhouse
2024-03-13 14:50                     ` Alexandre Belloni
2024-03-13 20:12                       ` Andrew Lunn
2024-03-14  9:13                         ` Peter Hilber
2024-03-13 17:50                     ` Peter Hilber
2024-03-13 14:15               ` Peter Hilber
2024-03-13 12:45             ` David Woodhouse
2024-03-13 17:50               ` Peter Hilber
2024-03-13 18:18                 ` David Woodhouse
2024-03-14 10:13                   ` Peter Hilber
2024-03-14 14:19                     ` David Woodhouse
2024-03-19 13:47                       ` Peter Hilber
2024-03-20 17:22                         ` David Woodhouse
2024-06-15  8:40 ` David Woodhouse
2024-06-20 12:37   ` Peter Hilber
2024-06-20 16:19     ` David Woodhouse
2024-06-21  8:45       ` David Woodhouse
2024-06-25 19:01         ` [RFC PATCH v2] ptp: Add vDSO-style vmclock support David Woodhouse
2024-06-25 21:34           ` Thomas Gleixner
2024-06-25 21:48             ` David Woodhouse
2024-06-25 22:22               ` John Stultz
2024-06-26  8:32                 ` David Woodhouse
2024-06-26 16:43             ` Richard Cochran
2024-06-27 13:50           ` Peter Hilber
2024-06-27 14:52             ` David Woodhouse
2024-06-28 11:33               ` Peter Hilber
2024-06-28 12:15                 ` David Woodhouse
2024-06-28 16:38                   ` Peter Hilber
2024-06-28 21:27                     ` David Woodhouse
2024-07-01  8:57                       ` David Woodhouse
2024-07-02 15:03                         ` Peter Hilber
2024-07-02 16:39                           ` David Woodhouse
2024-07-02 18:12                             ` Peter Hilber
2024-07-02 18:40                               ` David Woodhouse
2024-07-03  9:56                                 ` Peter Hilber
2024-07-03 10:40                                   ` David Woodhouse
2024-07-05  8:12                                     ` Peter Hilber
2024-07-05 15:02                                       ` David Woodhouse
2024-07-06  7:50                                         ` Peter Hilber
2024-06-27 16:03             ` David Woodhouse [this message]
2024-06-28 11:33               ` Peter Hilber
2024-06-28 11:41                 ` David Woodhouse
2024-06-30 13:28           ` Simon Horman
2024-07-01  8:02             ` David Woodhouse
2024-07-01 15:39               ` Kees Cook
2024-07-03  8:00                 ` David Woodhouse
2024-06-27 13:50         ` [RFC PATCH v3 0/7] Add virtio_rtc module and related changes Peter Hilber
2024-06-21 14:02     ` David Woodhouse

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=51dcda5b675fb68c54b74fd19c408a3a086fc412.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=christopher.s.hall@intel.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=jasowang@redhat.com \
    --cc=jstultz@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=peter.hilber@opensynergy.com \
    --cc=richardcochran@gmail.com \
    --cc=ridouxj@amazon.com \
    --cc=rluu@amazon.com \
    --cc=sboyd@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=virtio-dev@lists.linux.dev \
    --cc=virtualization@lists.linux.dev \
    --cc=xuanzhuo@linux.alibaba.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).