David!

On Thu, Feb 06 2025 at 09:31, David Woodhouse wrote:

Thanks for working on this. Is there a plan to expose the time data
directly to userspace in a form which is usable *other* than by
function calls which get the value of the clock at a given moment?

For populating the vmclock device¹ we need to know the actual
relationship between the hardware counter (TSC, arch timer, etc.) and
real time in order to propagate that to the guest.

I see two options for doing this:

 1. Via userspace, exposing the vdso time data (and a notification when
    it changes?) and letting the userspace VMM populate the vmclock.
    This is complex for x86 because of TSC scaling; in fact userspace
    doesn't currently know the precise scaling from host to guest TSC
    so we'd have to be able to extract that from KVM.

Exposing the raw data is not going to happen as we would create an ABI
preventing any modifications to the internals. VDSO data is considered a
fully internal (think kernel) representation and the accessor functions
create an ABI around it. So if at all you can add a accessor function
which exposes data to user space so that the internal data
representation can still be modified as necessary.

 2. In kernel, asking KVM to populate the vmclock structure much like
    it does other pvclocks shared with the guest. KVM/x86 already uses
    pvclock_gtod_register_notifier() to hook changes; should we expand
    on that? The problem with that notifier is that it seems to be
    called far more frequently than I'd expect.

It's called once per tick to expose the continous updates to the
conversion factors and related internal data.

Thanks,

        tglx