[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ea7c5eda8180904a6caf476c56973a06bd4b5e78.camel@infradead.org>
Date: Tue, 25 Jun 2024 22:48:22 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>, 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>
Cc: "Christopher S. Hall" <christopher.s.hall@...el.com>, Jason Wang
<jasowang@...hat.com>, John Stultz <jstultz@...gle.com>, "Michael S.
Tsirkin" <mst@...hat.com>, netdev@...r.kernel.org, Richard Cochran
<richardcochran@...il.com>, Stephen Boyd <sboyd@...nel.org>, 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>
Subject: Re: [RFC PATCH v2] ptp: Add vDSO-style vmclock support
On Tue, 2024-06-25 at 23:34 +0200, Thomas Gleixner wrote:
> On Tue, Jun 25 2024 at 20:01, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@...zon.co.uk>
> >
> > The vmclock "device" provides a shared memory region with precision clock
> > information. By using shared memory, it is safe across Live Migration.
> >
> > Like the KVM PTP clock, this can convert TSC-based cross timestamps into
> > KVM clock values. Unlike the KVM PTP clock, it does so only when such is
> > actually helpful.
> >
> > The memory region of the device is also exposed to userspace so it can be
> > read or memory mapped by application which need reliable notification of
> > clock disruptions.
>
> There is effort underway to expose PTP clocks to user space via VDSO.
Ooh, interesting. Got a reference to that please?
> Can we please not expose an ad hoc interface for that?
Absolutely. I'm explicitly trying to intercept the virtio-rtc
specification here, to *avoid* having to do anything ad hoc.
Note that this is a "vDSO-style" interface from hypervisor to guest via
a shared memory region, not necessarily an actual vDSO.
But yes, it *is* intended to be exposed to userspace, so that userspace
can know the *accurate* time without a system call, and know that it
hasn't been perturbed by live migration.
> As you might have heard the sad news, I'm not feeling up to the task to
> dig deeper into this right now. Give me a couple of days to look at this
> with working brain.
I have not heard any news, although now I'm making inferences.
Wishing you the best!
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)
Powered by blists - more mailing lists