[PATCH] ptp: Add vDSO-style vmclock support

[David Woodhouse]

On Thu, 2024-07-25 at 12:38 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 04:18:43PM +0100, David Woodhouse wrote:
> > The use case isn't necessarily for all users of gettimeofday(), of
> > course; this is for those applications which *need* precision time.
> > Like distributed databases which rely on timestamps for coherency, and
> > users who get fined millions of dollars when LM messes up their clocks
> > and they put wrong timestamps on financial transactions.
> 
> I would however worry that with all this pass through,
> applications have to be coded to each hypervisor or even
> version of the hypervisor.

Yes, that would be a problem. Which is why I feel it's so important to
harmonise the contents of the shared memory, and I'm implementing it
both QEMU and $DAYJOB, as well as aligning with virtio-rtc.

I don't think the structure should be changing between hypervisors (and
especially versions). We *will* see a progression from simply providing
the disruption signal, to providing the full clock information so that
guests don't have to abort transactions while they resync their clock.
But that's perfectly fine.

And it's also entirely agnostic to the mechanism by which the memory
region is *discovered*. It doesn't matter if it's ACPI, DT, a
hypervisor enlightenment, a BAR of a simple PCI device, virtio, or
anything else.

ACPI is one of the *simplest* options for a hypervisor and guest to
implement, and doesn't prevent us from using the same structure in
virtio-rtc. I'm happy enough using ACPI and letting virtio-rtc come
along later.

> virtio has been developed with the painful experience that we keep
> making mistakes, or coming up with new needed features,
> and that maintaining forward and backward compatibility
> becomes a whole lot harder than it seems in the beginning.

Yes. But as you note, this shared memory structure is a userspace ABI
all of its own, so we get to make a completely *different* kind of
mistake :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5965 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240725/57938d3f/attachment.p7s>