Re: [RFC PATCH 0/2] Introduce a way to adjust CLOCK_BOOTTIME from userspace for VM guests

Re: [RFC PATCH 0/2] Introduce a way to adjust CLOCK_BOOTTIME from userspace for VM guests

[Alexander Graf]

On 10.02.21 11:39, Hikaru Nishida wrote:
> 
> From: Hikaru Nishida <hikalium@chromium.org>
> 
> 
> Hi folks,
> 
> We'd like to add a sysfs interface that enable us to advance
> CLOCK_BOOTTIME from userspace. The use case of this change is that
> adjusting guest's CLOCK_BOOTTIME as host suspends to ensure that the
> guest can notice the device has been suspended.
> We have an application that rely on the difference between
> CLOCK_BOOTTIME and CLOCK_MONOTONIC to detect whether the device went
> suspend or not. However, the logic did not work well on VM environment
> since most VMs are pausing the VM guests instead of actually suspending
> them on the host's suspension.
> With following patches, we can adjust CLOCK_BOOTTIME without actually
> suspending guest and make the app working as intended.
> I think this feature is also useful for other VM solutions since there
> was no way to do this from userspace.
> 
> As far as I checked, it is working as expected but is there any concern
> about this change? If so, please let me know.

I don't fully grasp why you want the guest to manually adjust its 
CLOCK_BOOTTIME. Wouldn't it make more sense to extend kvmclock's notion 
of wall clock time to tell you about suspended vs executed wall clock?


Alex




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

Re: [RFC PATCH 2/2] drivers/virt: introduce CLOCK_BOOTTIME adjustment sysfs interface driver

[Thomas Gleixner]

On Wed, Feb 10 2021 at 19:39, Hikaru Nishida wrote:
> From: Hikaru Nishida <hikalium@chromium.org>
>
> This adds a sysfs interface /sys/kernel/boottime_adj to enable advancing
> CLOCK_BOOTTIME from the userspace without actual susupend/resume cycles.
>
> This gives a way to mitigate CLOCK_BOOTTIME divergence between guest
> and host on virtualized environments after suspend/resume cycles on
> the host.
>
> We observed an issue of a guest application that expects there is a gap
> between CLOCK_BOOTTIME and CLOCK_MONOTONIC after the device is suspended
> to detect whether the device went into suspend or not.
> Since the guest is paused instead of being actually suspended during the
> host's suspension, guest kernel doesn't advance CLOCK_BOOTTIME correctly
> and there is no way to correct that.
>
> To solve the problem, this change introduces a way to modify a gap
> between those clocks and align the timer behavior to host's one.

That's not a solution, that's a bandaid and just creating a horrible
user space ABI which we can't get rid off anymore.

The whole approach of virt vs. pausing and timekeeping is busted as I
pointed out several times before. Just papering over it with random
interfaces which fiddle with the timekeeping internals is not going to
happen.

Thanks,

        tglx