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 :)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
