This RFC is to try to solve the following problem:
We have some applications that are currently running in their
own namespace, that still talk to other processes on the
machine, using IPC, and expect to run on the same machine.
We want to move them into a virtual machine, for the usual
benefits of virtualization.
However, some of these programs use CLOCK_MONOTONIC and
CLOCK_BOOTTIME timestamps, as part of their protocol, when talking
to the host.
Generally speaking, we have multiple event sources, for example
sensors, input devices, display controller vsync, etc and we would
like to rely on them in the guest for various scenarios.
As a specific example, we are trying to run some wayland clients
(in the guest) who talk to the server (in the host), and the server
gives input events based on host time. Additionally, there are also
vsync events that the clients use for timing their rendering.
Another use case we have are timestamps from IIO sensors and cameras.
There are applications that need to determine how the timestamps
relate to the current time and the only way to get current time is
clock_gettime(), which would return a value from a different time
domain than the timestamps.
In this case, it is not feasible to change these programs, due to
the number of the places we would have to change.
We spent some time thinking about this, and the best solution we
could come up with was the following:
Make the guest kernel return the same CLOCK_MONOTONIC and
CLOCK_GETTIME timestamps as the host.
To do that, I am changing kvmclock to request to the host to copy
its timekeeping parameters (mult, base, cycle_last, etc), so that
the guest timekeeper can use the same values, so that time can
be synchronized between the guest and the host.
Any suggestions or feedback would be highly appreciated.
Changes in v2:
- Move out of kvmclock and into its own clocksource and file.
- Remove timekeeping.c #ifdefs.
- Fix i386 build.
Suleiman Souhlal (2):
kvm: Mechanism to copy host timekeeping parameters into guest.
x86/kvmclock: Introduce kvm-hostclock clocksource.
arch/x86/Kconfig | 9 ++
arch/x86/include/asm/kvm_host.h | 3 +
arch/x86/include/asm/kvmclock.h | 12 +++
arch/x86/include/asm/pvclock-abi.h | 27 ++++++
arch/x86/include/uapi/asm/kvm_para.h | 1 +
arch/x86/kernel/Makefile | 2 +
arch/x86/kernel/kvmclock.c | 5 +-
arch/x86/kernel/kvmhostclock.c | 130 +++++++++++++++++++++++++++
arch/x86/kvm/x86.c | 121 +++++++++++++++++++++++++
include/linux/timekeeper_internal.h | 8 ++
kernel/time/timekeeping.c | 2 +
11 files changed, 319 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/kernel/kvmhostclock.c
--
2.23.0.581.g78d2f28ef7-goog
On Thu, Oct 10, 2019 at 04:30:53PM +0900, Suleiman Souhlal wrote:
> This RFC is to try to solve the following problem:
>
> We have some applications that are currently running in their
> own namespace, that still talk to other processes on the
> machine, using IPC, and expect to run on the same machine.
>
> We want to move them into a virtual machine, for the usual
> benefits of virtualization.
>
> However, some of these programs use CLOCK_MONOTONIC and
> CLOCK_BOOTTIME timestamps, as part of their protocol, when talking
> to the host.
>
> Generally speaking, we have multiple event sources, for example
> sensors, input devices, display controller vsync, etc and we would
> like to rely on them in the guest for various scenarios.
>
> As a specific example, we are trying to run some wayland clients
> (in the guest) who talk to the server (in the host), and the server
> gives input events based on host time. Additionally, there are also
> vsync events that the clients use for timing their rendering.
>
> Another use case we have are timestamps from IIO sensors and cameras.
> There are applications that need to determine how the timestamps
> relate to the current time and the only way to get current time is
> clock_gettime(), which would return a value from a different time
> domain than the timestamps.
>
> In this case, it is not feasible to change these programs, due to
> the number of the places we would have to change.
>
> We spent some time thinking about this, and the best solution we
> could come up with was the following:
>
> Make the guest kernel return the same CLOCK_MONOTONIC and
> CLOCK_GETTIME timestamps as the host.
>
> To do that, I am changing kvmclock to request to the host to copy
> its timekeeping parameters (mult, base, cycle_last, etc), so that
> the guest timekeeper can use the same values, so that time can
> be synchronized between the guest and the host.
I wonder how feasible it is to map the host's vdso into the guest and
thus make the guest use the *same* (as opposed to "synchronized") clock
as the host's userspace? Another benefit is that it's essentially an
ABI so is not changed as liberally as internal structures like
timekeeper, etc. There is probably certain complication in handling the
syscall fallback in the vdso when used in the guest kernel, though.
You'll also need to ensure neither tsc scaling and nor offsetting is
applied to the VM once this clock is enabled.
Roman.
On 10/10/19 09:30, Suleiman Souhlal wrote:
>
> Changes in v2:
> - Move out of kvmclock and into its own clocksource and file.
> - Remove timekeeping.c #ifdefs.
> - Fix i386 build.
This is now pretty clean, so my objections are more or less gone. I
haven't put much thought into this, but are all fields of struct
timekeeping necessary? Some of them are redundant with the existing
wallclock MSRs. The handling of versioning probably varies depending on
the exact set of fields, too.
Paolo
.snip..
> I wonder how feasible it is to map the host's vdso into the guest and
> thus make the guest use the *same* (as opposed to "synchronized") clock
> as the host's userspace? Another benefit is that it's essentially an
> ABI so is not changed as liberally as internal structures like
> timekeeper, etc. There is probably certain complication in handling the
> syscall fallback in the vdso when used in the guest kernel, though.
>
> You'll also need to ensure neither tsc scaling and nor offsetting is
> applied to the VM once this clock is enabled.
This is how Xen does it - you can register the hypervisor to timestamp
your vDSO regions if you want it. See xen_setup_vsyscall_time_info
>
> Roman.
On Thu, Oct 10, 2019 at 7:39 PM Roman Kagan <[email protected]> wrote:
>
> I wonder how feasible it is to map the host's vdso into the guest and
> thus make the guest use the *same* (as opposed to "synchronized") clock
> as the host's userspace? Another benefit is that it's essentially an
> ABI so is not changed as liberally as internal structures like
> timekeeper, etc. There is probably certain complication in handling the
> syscall fallback in the vdso when used in the guest kernel, though.
>
> You'll also need to ensure neither tsc scaling and nor offsetting is
> applied to the VM once this clock is enabled.
That is what I initially wanted to do, but I couldn't find an easy way
to map a host page into the guest, outside of the regular userspace
(ioctl) KVM way of adding memory to a VM.
-- Suleiman