On Fri, 2025-02-14 at 12:34 +0100, Thomas Gleixner wrote:
> > 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?
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 de
On Thu, 2025-02-06 at 11:59 +0100, Thomas Weißschuh wrote:
> On Thu, Feb 06, 2025 at 09:31:42AM +, David Woodhouse wrote:
> > On Tue, 2025-02-04 at 13:05 +0100, Thomas Weißschuh wrote:
> > > Currently each architecture defines the setup of the vDSO data page on
> > > its own, mostly through cop
On Thu, Feb 06, 2025 at 09:31:42AM +, David Woodhouse wrote:
> On Tue, 2025-02-04 at 13:05 +0100, Thomas Weißschuh wrote:
> > Currently each architecture defines the setup of the vDSO data page on
> > its own, mostly through copy-and-paste from some other architecture.
> > Extend the existing g
On Tue, 2025-02-04 at 13:05 +0100, Thomas Weißschuh wrote:
> Currently each architecture defines the setup of the vDSO data page on
> its own, mostly through copy-and-paste from some other architecture.
> Extend the existing generic vDSO implementation to also provide generic
> data storage.
> This
Currently each architecture defines the setup of the vDSO data page on
its own, mostly through copy-and-paste from some other architecture.
Extend the existing generic vDSO implementation to also provide generic
data storage.
This removes duplicated code and paves the way for further changes to
the
