| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20240729113320-mutt-send-email-mst@kernel.org>
Date: Mon, 29 Jul 2024 11:33:36 -0400
From: "Michael S. Tsirkin" <mst@...hat.com>
To: David Woodhouse <dwmw2@...radead.org>
Cc: Richard Cochran <richardcochran@...il.com>,
Peter Hilber <peter.hilber@...nsynergy.com>,
linux-kernel@...r.kernel.org, virtualization@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, linux-rtc@...r.kernel.org,
"Ridoux, Julien" <ridouxj@...zon.com>, virtio-dev@...ts.linux.dev,
"Luu, Ryan" <rluu@...zon.com>,
"Chashper, David" <chashper@...zon.com>,
"Mohamed Abuelfotoh, Hazem" <abuehaze@...zon.com>,
"Christopher S . Hall" <christopher.s.hall@...el.com>,
Jason Wang <jasowang@...hat.com>, John Stultz <jstultz@...gle.com>,
netdev@...r.kernel.org, Stephen Boyd <sboyd@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
Marc Zyngier <maz@...nel.org>, Mark Rutland <mark.rutland@....com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Alessandro Zummo <a.zummo@...ertech.it>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
qemu-devel <qemu-devel@...gnu.org>, Simon Horman <horms@...nel.org>
Subject: Re: [PATCH v3] ptp: Add vDSO-style vmclock support
On Mon, Jul 29, 2024 at 11:42:22AM +0100, David Woodhouse wrote:
> +struct vmclock_abi {
> + /* CONSTANT FIELDS */
> + uint32_t magic;
> +#define VMCLOCK_MAGIC 0x4b4c4356 /* "VCLK" */
> + uint32_t size; /* Size of region containing this structure */
> + uint16_t version; /* 1 */
> + uint8_t counter_id; /* Matches VIRTIO_RTC_COUNTER_xxx except INVALID */
> +#define VMCLOCK_COUNTER_ARM_VCNT 0
> +#define VMCLOCK_COUNTER_X86_TSC 1
> +#define VMCLOCK_COUNTER_INVALID 0xff
> + uint8_t time_type; /* Matches VIRTIO_RTC_TYPE_xxx */
> +#define VMCLOCK_TIME_UTC 0 /* Since 1970-01-01 00:00:00z */
> +#define VMCLOCK_TIME_TAI 1 /* Since 1970-01-01 00:00:00z */
> +#define VMCLOCK_TIME_MONOTONIC 2 /* Since undefined epoch */
> +#define VMCLOCK_TIME_INVALID_SMEARED 3 /* Not supported */
> +#define VMCLOCK_TIME_INVALID_MAYBE_SMEARED 4 /* Not supported */
> +
> + /* NON-CONSTANT FIELDS PROTECTED BY SEQCOUNT LOCK */
> + uint32_t seq_count; /* Low bit means an update is in progress */
> + /*
> + * 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;
> + uint64_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 which provides latency-sensitive services may wish to
> + * remove itself from service if an event is coming up. Two flags
> + * indicate the approximate imminence of the event.
> + */
> +#define VMCLOCK_FLAG_DISRUPTION_SOON (1 << 1) /* About a day */
> +#define VMCLOCK_FLAG_DISRUPTION_IMMINENT (1 << 2) /* About an hour */
> +#define VMCLOCK_FLAG_PERIOD_ESTERROR_VALID (1 << 3)
> +#define VMCLOCK_FLAG_PERIOD_MAXERROR_VALID (1 << 4)
> +#define VMCLOCK_FLAG_TIME_ESTERROR_VALID (1 << 5)
> +#define VMCLOCK_FLAG_TIME_MAXERROR_VALID (1 << 6)
> + /*
> + * If the MONOTONIC flag is set then (other than leap seconds) it is
> + * guaranteed that the time calculated according this structure at
> + * any given moment shall never appear to be later than the time
> + * calculated via the structure at any *later* moment.
> + *
> + * In particular, a timestamp based on a counter reading taken
> + * immediately after setting the low bit of seq_count (and the
> + * associated memory barrier), using the previously-valid time and
> + * period fields, shall never be later than a timestamp based on
> + * a counter reading taken immediately before *clearing* the low
> + * bit again after the update, using the about-to-be-valid fields.
> + */
> +#define VMCLOCK_FLAG_TIME_MONOTONIC (1 << 7)
> +
> + uint8_t pad[2];
> + 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
> +
> + /*
> + * The time exposed through this device is never smeared. This field
> + * corresponds to the 'subtype' field in virtio-rtc, which indicates
> + * the smearing method. However in this case it 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
> + * UTC, it may do so in a fashion consistent with the other systems
> + * in the nearby environment.
> + */
> + uint8_t leap_second_smearing_hint; /* Matches VIRTIO_RTC_SUBTYPE_xxx */
> +#define VMCLOCK_SMEARING_STRICT 0
> +#define VMCLOCK_SMEARING_NOON_LINEAR 1
> +#define VMCLOCK_SMEARING_UTC_SLS 2
> + int16_t tai_offset_sec;
> + uint8_t leap_indicator;
> + /*
> + * This field is based on the the VIRTIO_RTC_LEAP_xxx values as
> + * defined in the current draft of virtio-rtc, but since smearing
> + * cannot be used with the shared memory device, some values are
> + * not used.
> + *
> + * The _POST_POS and _POST_NEG values allow the guest to perform
> + * its own smearing during the day or so after a leap second when
> + * such smearing may need to continue being applied for a leap
> + * second which is now theoretically "historical".
> + */
> +#define VMCLOCK_LEAP_NONE 0x00 /* No known nearby leap second */
> +#define VMCLOCK_LEAP_PRE_POS 0x01 /* Positive leap second at EOM */
> +#define VMCLOCK_LEAP_PRE_NEG 0x02 /* Negative leap second at EOM */
> +#define VMCLOCK_LEAP_POS 0x03 /* Set during 23:59:60 second */
> +#define VMCLOCK_LEAP_POST_POS 0x04
> +#define VMCLOCK_LEAP_POST_NEG 0x05
> +
> + /* Bit shift for counter_period_frac_sec and its error rate */
> + uint8_t counter_period_shift;
> + /*
> + * Paired values of counter and UTC at a given point in time.
> + */
> + uint64_t counter_value;
> + /*
> + * Counter period, and error margin of same. The unit of these
> + * fields is 1/2^(64 + counter_period_shift) of a second.
> + */
> + uint64_t counter_period_frac_sec;
> + uint64_t counter_period_esterror_rate_frac_sec;
> + uint64_t counter_period_maxerror_rate_frac_sec;
> +
> + /*
> + * Time according to time_type field above.
> + */
> + uint64_t time_sec; /* Seconds since time_type epoch */
> + uint64_t time_frac_sec; /* Units of 1/2^64 of a second */
> + uint64_t time_esterror_nanosec;
> + uint64_t time_maxerror_nanosec;
> +};
> +
> +#endif /* __VMCLOCK_ABI_H__ */
> --
> 2.44.0
>
>
you said you will use __le here?
Powered by blists - more mailing lists