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 --]
next prev 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).