From: Marc Zyngier <maz@kernel.org> Date: 2021-03-30 14:55:32
Given that this series[0] has languished in my Inbox for the best of the
past two years, and in an effort to eventually get it merged, I've
taken the liberty to pick it up and do the changes I wanted to see
instead of waiting to go through yet another round.
All the patches have a link to their original counterpart (though I
have squashed a couple of them where it made sense). Tested both 64
and 32bit guests for a good measure. Of course, I claim full
responsibility for any bug introduced here.
Unless someone screams now, this is going in 5.13, because I'm frankly
fed up with it! ;-)
* From v18 [2]
- Fix kvm_hypercall2() return type
- Rebased on top of 5.12-rc3
- Added RBs
* From v17 [1]:
- Fixed compilation issue on 32bit systems not selecting
CONFIG_HAVE_ARM_SMCCC_DISCOVERY
- Fixed KVM service discovery not properly parsing the reply
from the hypervisor
* From v16 [0]:
- Moved the KVM service discovery to its own file, plugged it into
PSCI instead of the arch code, dropped the inlining, made use of
asm/hypervisor.h.
- Tidied-up the namespacing
- Cleanup the hypercall handler
- De-duplicate the guest code
- Tidied-up arm64-specific documentation
- Dropped the generic PTP documentation as it needs a new location,
and some cleanup
- Squashed hypercall documentation and capability into the
main KVM patch
- Rebased on top of 5.11-rc4
[0] https://lore.kernel.org/r/20201209060932.212364-1-jianyong.wu@arm.com
[1] https://lore.kernel.org/r/20210202141204.3134855-1-maz@kernel.org
[2] https://lore.kernel.org/r/20210208134029.3269384-1-maz@kernel.org
Jianyong Wu (4):
ptp: Reorganize ptp_kvm.c to make it arch-independent
clocksource: Add clocksource id for arm arch counter
KVM: arm64: Add support for the KVM PTP service
ptp: arm/arm64: Enable ptp_kvm for arm/arm64
Thomas Gleixner (1):
time: Add mechanism to recognize clocksource in time_get_snapshot
Will Deacon (2):
arm/arm64: Probe for the presence of KVM hypervisor
KVM: arm64: Advertise KVM UID to guests via SMCCC
Documentation/virt/kvm/api.rst | 10 +++
Documentation/virt/kvm/arm/index.rst | 1 +
Documentation/virt/kvm/arm/ptp_kvm.rst | 25 ++++++
arch/arm/include/asm/hypervisor.h | 3 +
arch/arm64/include/asm/hypervisor.h | 3 +
arch/arm64/kvm/arm.c | 1 +
arch/arm64/kvm/hypercalls.c | 80 +++++++++++++++--
drivers/clocksource/arm_arch_timer.c | 36 ++++++++
drivers/firmware/psci/psci.c | 2 +
drivers/firmware/smccc/Makefile | 2 +-
drivers/firmware/smccc/kvm_guest.c | 50 +++++++++++
drivers/firmware/smccc/smccc.c | 1 +
drivers/ptp/Kconfig | 2 +-
drivers/ptp/Makefile | 2 +
drivers/ptp/ptp_kvm_arm.c | 28 ++++++
drivers/ptp/{ptp_kvm.c => ptp_kvm_common.c} | 84 +++++-------------
drivers/ptp/ptp_kvm_x86.c | 97 +++++++++++++++++++++
include/linux/arm-smccc.h | 41 +++++++++
include/linux/clocksource.h | 6 ++
include/linux/clocksource_ids.h | 12 +++
include/linux/ptp_kvm.h | 19 ++++
include/linux/timekeeping.h | 12 +--
include/uapi/linux/kvm.h | 1 +
kernel/time/clocksource.c | 2 +
kernel/time/timekeeping.c | 1 +
25 files changed, 443 insertions(+), 78 deletions(-)
create mode 100644 Documentation/virt/kvm/arm/ptp_kvm.rst
create mode 100644 drivers/firmware/smccc/kvm_guest.c
create mode 100644 drivers/ptp/ptp_kvm_arm.c
rename drivers/ptp/{ptp_kvm.c => ptp_kvm_common.c} (60%)
create mode 100644 drivers/ptp/ptp_kvm_x86.c
create mode 100644 include/linux/clocksource_ids.h
create mode 100644 include/linux/ptp_kvm.h
--
2.29.2
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-30 14:55:31
From: Will Deacon <will@kernel.org>
Although the SMCCC specification provides some limited functionality for
describing the presence of hypervisor and firmware services, this is
generally applicable only to functions designated as "Arm Architecture
Service Functions" and no portable discovery mechanism is provided for
standard hypervisor services, despite having a designated range of
function identifiers reserved by the specification.
In an attempt to avoid the need for additional firmware changes every
time a new function is added, introduce a UID to identify the service
provider as being compatible with KVM. Once this has been established,
additional services can be discovered via a feature bitmap.
Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Jianyong Wu <redacted>
[maz: move code to its own file, plug it into PSCI]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201209060932.212364-2-jianyong.wu@arm.com
---
arch/arm/include/asm/hypervisor.h | 3 ++
arch/arm64/include/asm/hypervisor.h | 3 ++
drivers/firmware/psci/psci.c | 2 ++
drivers/firmware/smccc/Makefile | 2 +-
drivers/firmware/smccc/kvm_guest.c | 50 +++++++++++++++++++++++++++++
drivers/firmware/smccc/smccc.c | 1 +
include/linux/arm-smccc.h | 25 +++++++++++++++
7 files changed, 85 insertions(+), 1 deletion(-)
create mode 100644 drivers/firmware/smccc/kvm_guest.c
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-30 14:55:32
From: Will Deacon <will@kernel.org>
We can advertise ourselves to guests as KVM and provide a basic features
bitmap for discoverability of future hypervisor services.
Cc: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Jianyong Wu <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201209060932.212364-3-jianyong.wu@arm.com
---
arch/arm64/kvm/hypercalls.c | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/ptp/ptp_kvm.c b/drivers/ptp/ptp_kvm_common.csimilarity index 60%rename from drivers/ptp/ptp_kvm.crename to drivers/ptp/ptp_kvm_common.cindex 658d33fc3195..721ddcede5e1 100644--- a/drivers/ptp/ptp_kvm.c+++ b/drivers/ptp/ptp_kvm_common.c
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-30 14:55:33
From: Thomas Gleixner <redacted>
System time snapshots are not conveying information about the current
clocksource which was used, but callers like the PTP KVM guest
implementation have the requirement to evaluate the clocksource type to
select the appropriate mechanism.
Introduce a clocksource id field in struct clocksource which is by default
set to CSID_GENERIC (0). Clocksource implementations can set that field to
a value which allows to identify the clocksource.
Store the clocksource id of the current clocksource in the
system_time_snapshot so callers can evaluate which clocksource was used to
take the snapshot and act accordingly.
Signed-off-by: Thomas Gleixner <redacted>
Signed-off-by: Jianyong Wu <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201209060932.212364-5-jianyong.wu@arm.com
---
include/linux/clocksource.h | 6 ++++++
include/linux/clocksource_ids.h | 11 +++++++++++
include/linux/timekeeping.h | 12 +++++++-----
kernel/time/clocksource.c | 2 ++
kernel/time/timekeeping.c | 1 +
5 files changed, 27 insertions(+), 5 deletions(-)
create mode 100644 include/linux/clocksource_ids.h
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-30 14:55:33
From: Jianyong Wu <redacted>
Implement the hypervisor side of the KVM PTP interface.
The service offers wall time and cycle count from host to guest.
The caller must specify whether they want the host's view of
either the virtual or physical counter.
Signed-off-by: Jianyong Wu <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201209060932.212364-7-jianyong.wu@arm.com
---
Documentation/virt/kvm/api.rst | 10 +++++
Documentation/virt/kvm/arm/index.rst | 1 +
Documentation/virt/kvm/arm/ptp_kvm.rst | 25 ++++++++++++
arch/arm64/kvm/arm.c | 1 +
arch/arm64/kvm/hypercalls.c | 53 ++++++++++++++++++++++++++
include/linux/arm-smccc.h | 16 ++++++++
include/uapi/linux/kvm.h | 1 +
7 files changed, 107 insertions(+)
create mode 100644 Documentation/virt/kvm/arm/ptp_kvm.rst
@@ -6724,3 +6724,13 @@ vcpu_info is set. The KVM_XEN_HVM_CONFIG_RUNSTATE flag indicates that the runstate-related features KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADDR/_CURRENT/_DATA/_ADJUST are supported by the KVM_XEN_VCPU_SET_ATTR/KVM_XEN_VCPU_GET_ATTR ioctls.++8.31 KVM_CAP_PTP_KVM+--------------------++:Architectures: arm64++This capability indicates that the KVM virtual PTP service is+supported in the host. A VMM can check whether the service is+available to the guest on migration.+
@@ -0,0 +1,25 @@+.. SPDX-License-Identifier: GPL-2.0++PTP_KVM support for arm/arm64+=============================++PTP_KVM is used for high precision time sync between host and guests.+It relies on transferring the wall clock and counter value from the+host to the guest using a KVM-specific hypercall.++* ARM_SMCCC_HYP_KVM_PTP_FUNC_ID: 0x86000001++This hypercall uses the SMC32/HVC32 calling convention:++ARM_SMCCC_HYP_KVM_PTP_FUNC_ID+ ============= ========== ==========+ Function ID: (uint32) 0x86000001+ Arguments: (uint32) KVM_PTP_VIRT_COUNTER(0)+ KVM_PTP_PHYS_COUNTER(1)+ Return Values: (int32) NOT_SUPPORTED(-1) on error, or+ (uint32) Upper 32 bits of wall clock time (r0)+ (uint32) Lower 32 bits of wall clock time (r1)+ (uint32) Upper 32 bits of counter (r2)+ (uint32) Lower 32 bits of counter (r3)+ Endianness: No Restrictions.+ ============= ========== ==========
@@ -206,6 +206,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)caseKVM_CAP_ARM_INJECT_EXT_DABT:caseKVM_CAP_SET_GUEST_DEBUG:caseKVM_CAP_VCPU_ATTRIBUTES:+caseKVM_CAP_PTP_KVM:r=1;break;caseKVM_CAP_ARM_SET_DEVICE_ADDR:
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-30 14:55:33
From: Jianyong Wu <redacted>
Currently, there is no mechanism to keep time sync between guest and host
in arm/arm64 virtualization environment. Time in guest will drift compared
with host after boot up as they may both use third party time sources
to correct their time respectively. The time deviation will be in order
of milliseconds. But in some scenarios,like in cloud environment, we ask
for higher time precision.
kvm ptp clock, which chooses the host clock source as a reference
clock to sync time between guest and host, has been adopted by x86
which takes the time sync order from milliseconds to nanoseconds.
This patch enables kvm ptp clock for arm/arm64 and improves clock sync precision
significantly.
Test result comparisons between with kvm ptp clock and without it in arm/arm64
are as follows. This test derived from the result of command 'chronyc
sources'. we should take more care of the last sample column which shows
the offset between the local clock and the source at the last measurement.
no kvm ptp in guest:
MS Name/IP address Stratum Poll Reach LastRx Last sample
========================================================================
^* dns1.synet.edu.cn 2 6 377 13 +1040us[+1581us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 21 +1040us[+1581us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 29 +1040us[+1581us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 37 +1040us[+1581us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 45 +1040us[+1581us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 53 +1040us[+1581us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 61 +1040us[+1581us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 4 -130us[ +796us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 12 -130us[ +796us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 20 -130us[ +796us] +/- 21ms
in host:
MS Name/IP address Stratum Poll Reach LastRx Last sample
========================================================================
^* 120.25.115.20 2 7 377 72 -470us[ -603us] +/- 18ms
^* 120.25.115.20 2 7 377 92 -470us[ -603us] +/- 18ms
^* 120.25.115.20 2 7 377 112 -470us[ -603us] +/- 18ms
^* 120.25.115.20 2 7 377 2 +872ns[-6808ns] +/- 17ms
^* 120.25.115.20 2 7 377 22 +872ns[-6808ns] +/- 17ms
^* 120.25.115.20 2 7 377 43 +872ns[-6808ns] +/- 17ms
^* 120.25.115.20 2 7 377 63 +872ns[-6808ns] +/- 17ms
^* 120.25.115.20 2 7 377 83 +872ns[-6808ns] +/- 17ms
^* 120.25.115.20 2 7 377 103 +872ns[-6808ns] +/- 17ms
^* 120.25.115.20 2 7 377 123 +872ns[-6808ns] +/- 17ms
The dns1.synet.edu.cn is the network reference clock for guest and
120.25.115.20 is the network reference clock for host. we can't get the
clock error between guest and host directly, but a roughly estimated value
will be in order of hundreds of us to ms.
with kvm ptp in guest:
chrony has been disabled in host to remove the disturb by network clock.
MS Name/IP address Stratum Poll Reach LastRx Last sample
========================================================================
* PHC0 0 3 377 8 -7ns[ +1ns] +/- 3ns
* PHC0 0 3 377 8 +1ns[ +16ns] +/- 3ns
* PHC0 0 3 377 6 -4ns[ -0ns] +/- 6ns
* PHC0 0 3 377 6 -8ns[ -12ns] +/- 5ns
* PHC0 0 3 377 5 +2ns[ +4ns] +/- 4ns
* PHC0 0 3 377 13 +2ns[ +4ns] +/- 4ns
* PHC0 0 3 377 12 -4ns[ -6ns] +/- 4ns
* PHC0 0 3 377 11 -8ns[ -11ns] +/- 6ns
* PHC0 0 3 377 10 -14ns[ -20ns] +/- 4ns
* PHC0 0 3 377 8 +4ns[ +5ns] +/- 4ns
The PHC0 is the ptp clock which choose the host clock as its source
clock. So we can see that the clock difference between host and guest
is in order of ns.
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Jianyong Wu <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201209060932.212364-8-jianyong.wu@arm.com
---
drivers/clocksource/arm_arch_timer.c | 34 ++++++++++++++++++++++++++++
drivers/ptp/Kconfig | 2 +-
drivers/ptp/Makefile | 1 +
drivers/ptp/ptp_kvm_arm.c | 28 +++++++++++++++++++++++
4 files changed, 64 insertions(+), 1 deletion(-)
create mode 100644 drivers/ptp/ptp_kvm_arm.c
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-30 14:56:00
From: Jianyong Wu <redacted>
Add clocksource id to the ARM generic counter so that it can be easily
identified from callers such as ptp_kvm.
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Jianyong Wu <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201209060932.212364-6-jianyong.wu@arm.com
---
drivers/clocksource/arm_arch_timer.c | 2 ++
include/linux/clocksource_ids.h | 1 +
2 files changed, 3 insertions(+)
From: Marc Zyngier <maz@kernel.org> Date: 2021-04-07 09:28:50
On Tue, 30 Mar 2021 15:54:26 +0100,
Marc Zyngier [off-list ref] wrote:
From: Jianyong Wu <redacted>
Currently, the ptp_kvm module contains a lot of x86-specific code.
Let's move this code into a new arch-specific file in the same directory,
and rename the arch-independent file to ptp_kvm_common.c.
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Jianyong Wu <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201209060932.212364-4-jianyong.wu@arm.com
Richard, Paolo,
Can I get an Ack on this and patch #7? We're getting pretty close to
the next merge window, and this series has been going on for a couple
of years now...
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
From: Richard Cochran <richardcochran@gmail.com> Date: 2021-04-07 15:13:42
On Wed, Apr 07, 2021 at 10:28:44AM +0100, Marc Zyngier wrote:
On Tue, 30 Mar 2021 15:54:26 +0100,
Marc Zyngier [off-list ref] wrote:
quoted
From: Jianyong Wu <redacted>
Currently, the ptp_kvm module contains a lot of x86-specific code.
Let's move this code into a new arch-specific file in the same directory,
and rename the arch-independent file to ptp_kvm_common.c.
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Jianyong Wu <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201209060932.212364-4-jianyong.wu@arm.com
Richard, Paolo,
Can I get an Ack on this and patch #7? We're getting pretty close to
the next merge window, and this series has been going on for a couple
of years now...
For both patches:
Acked-by: Richard Cochran <richardcochran@gmail.com>
From: Marc Zyngier <maz@kernel.org> Date: 2021-04-07 15:31:27
On Wed, 07 Apr 2021 16:13:34 +0100,
Richard Cochran [off-list ref] wrote:
On Wed, Apr 07, 2021 at 10:28:44AM +0100, Marc Zyngier wrote:
quoted
On Tue, 30 Mar 2021 15:54:26 +0100,
Marc Zyngier [off-list ref] wrote:
quoted
From: Jianyong Wu <redacted>
Currently, the ptp_kvm module contains a lot of x86-specific code.
Let's move this code into a new arch-specific file in the same directory,
and rename the arch-independent file to ptp_kvm_common.c.
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Jianyong Wu <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201209060932.212364-4-jianyong.wu@arm.com
Richard, Paolo,
Can I get an Ack on this and patch #7? We're getting pretty close to
the next merge window, and this series has been going on for a couple
of years now...
For both patches:
Acked-by: Richard Cochran <richardcochran@gmail.com>
Cheers Richard, much appreciated.
M.
--
Without deviation from the norm, progress is not possible.
+PTP_KVM support for arm/arm64
+=============================
+
+PTP_KVM is used for high precision time sync between host and guests.
+It relies on transferring the wall clock and counter value from the
+host to the guest using a KVM-specific hypercall.
+
+* ARM_SMCCC_HYP_KVM_PTP_FUNC_ID: 0x86000001
Per include/linux/arm-smccc.h, this should be
ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID.
+
+This hypercall uses the SMC32/HVC32 calling convention:
+
+ARM_SMCCC_HYP_KVM_PTP_FUNC_ID
+PTP_KVM support for arm/arm64
+=============================
+
+PTP_KVM is used for high precision time sync between host and guests.
+It relies on transferring the wall clock and counter value from the
+host to the guest using a KVM-specific hypercall.
+
+* ARM_SMCCC_HYP_KVM_PTP_FUNC_ID: 0x86000001
Per include/linux/arm-smccc.h, this should be
ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID.
Well spotted. Care to send a patch on top of my kvm-arm64/ptp branch?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
+PTP_KVM support for arm/arm64
+=============================
+
+PTP_KVM is used for high precision time sync between host and guests.
+It relies on transferring the wall clock and counter value from the
+host to the guest using a KVM-specific hypercall.
+
+* ARM_SMCCC_HYP_KVM_PTP_FUNC_ID: 0x86000001
Per include/linux/arm-smccc.h, this should be
ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID.
Well spotted. Care to send a patch on top of my kvm-arm64/ptp branch?
Hi Marc, Jianyong,
On Tue, Mar 30, 2021 at 4:56 PM Marc Zyngier [off-list ref] wrote:
From: Jianyong Wu <redacted>
Currently, there is no mechanism to keep time sync between guest and host
in arm/arm64 virtualization environment. Time in guest will drift compared
with host after boot up as they may both use third party time sources
to correct their time respectively. The time deviation will be in order
of milliseconds. But in some scenarios,like in cloud environment, we ask
for higher time precision.
kvm ptp clock, which chooses the host clock source as a reference
clock to sync time between guest and host, has been adopted by x86
which takes the time sync order from milliseconds to nanoseconds.
This patch enables kvm ptp clock for arm/arm64 and improves clock sync precision
significantly.
Why does this not depend on KVM_GUEST on ARM?
I.e. shouldn't the dependency be:
KVM_GUEST && (X86 || (HAVE_ARM_SMCCC_DISCOVERY && ARM_ARCH_TIMER))
?
default y
help
This driver adds support for using kvm infrastructure as a PTP
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
From: Marc Zyngier <maz@kernel.org> Date: 2021-05-11 09:13:09
Hi Geert,
On 2021-05-11 10:07, Geert Uytterhoeven wrote:
Hi Marc, Jianyong,
On Tue, Mar 30, 2021 at 4:56 PM Marc Zyngier [off-list ref] wrote:
quoted
From: Jianyong Wu <redacted>
Currently, there is no mechanism to keep time sync between guest and
host
in arm/arm64 virtualization environment. Time in guest will drift
compared
with host after boot up as they may both use third party time sources
to correct their time respectively. The time deviation will be in
order
of milliseconds. But in some scenarios,like in cloud environment, we
ask
for higher time precision.
kvm ptp clock, which chooses the host clock source as a reference
clock to sync time between guest and host, has been adopted by x86
which takes the time sync order from milliseconds to nanoseconds.
This patch enables kvm ptp clock for arm/arm64 and improves clock sync
precision
significantly.
Why does this not depend on KVM_GUEST on ARM?
I.e. shouldn't the dependency be:
KVM_GUEST && (X86 || (HAVE_ARM_SMCCC_DISCOVERY && ARM_ARCH_TIMER))
?
arm/arm64 do not select KVM_GUEST. Any kernel can be used for a guest,
and KVM/arm64 doesn't know about this configuration symbol.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Hi Marc,
On Tue, May 11, 2021 at 11:13 AM Marc Zyngier [off-list ref] wrote:
On 2021-05-11 10:07, Geert Uytterhoeven wrote:
quoted
On Tue, Mar 30, 2021 at 4:56 PM Marc Zyngier [off-list ref] wrote:
quoted
From: Jianyong Wu <redacted>
Currently, there is no mechanism to keep time sync between guest and
host
in arm/arm64 virtualization environment. Time in guest will drift
compared
with host after boot up as they may both use third party time sources
to correct their time respectively. The time deviation will be in
order
of milliseconds. But in some scenarios,like in cloud environment, we
ask
for higher time precision.
kvm ptp clock, which chooses the host clock source as a reference
clock to sync time between guest and host, has been adopted by x86
which takes the time sync order from milliseconds to nanoseconds.
This patch enables kvm ptp clock for arm/arm64 and improves clock sync
precision
significantly.
Why does this not depend on KVM_GUEST on ARM?
I.e. shouldn't the dependency be:
KVM_GUEST && (X86 || (HAVE_ARM_SMCCC_DISCOVERY && ARM_ARCH_TIMER))
?
arm/arm64 do not select KVM_GUEST. Any kernel can be used for a guest,
and KVM/arm64 doesn't know about this configuration symbol.
OK.
Does PTP_1588_CLOCK_KVM need to default to yes?
Perhaps only on X86, to maintain the status quo?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Why does this not depend on KVM_GUEST on ARM?
I.e. shouldn't the dependency be:
KVM_GUEST && (X86 || (HAVE_ARM_SMCCC_DISCOVERY && ARM_ARCH_TIMER))
?
arm/arm64 do not select KVM_GUEST. Any kernel can be used for a guest,
and KVM/arm64 doesn't know about this configuration symbol.
OK.
Does PTP_1588_CLOCK_KVM need to default to yes?
Perhaps only on X86, to maintain the status quo?
I think I don't really understand the problem you are trying to
solve. Is it that 'make oldconfig' now asks you about this new driver?
Why is that an issue?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
Why does this not depend on KVM_GUEST on ARM?
I.e. shouldn't the dependency be:
KVM_GUEST && (X86 || (HAVE_ARM_SMCCC_DISCOVERY && ARM_ARCH_TIMER))
?
arm/arm64 do not select KVM_GUEST. Any kernel can be used for a guest,
and KVM/arm64 doesn't know about this configuration symbol.
OK.
Does PTP_1588_CLOCK_KVM need to default to yes?
Perhaps only on X86, to maintain the status quo?
I think I don't really understand the problem you are trying to
solve. Is it that 'make oldconfig' now asks you about this new driver?
Why is that an issue?
My first "problem" was that it asked about this new driver on
arm/arm64, while I assumed there were some missing dependencies
(configuring a kernel should not ask useless questions). That turned
out to be a wrong assumption, so there is no such problem here.
The second problem is "default y": code that is not critical should
not be enabled by default. Hence my last question.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Why does this not depend on KVM_GUEST on ARM?
I.e. shouldn't the dependency be:
KVM_GUEST && (X86 || (HAVE_ARM_SMCCC_DISCOVERY && ARM_ARCH_TIMER))
?
arm/arm64 do not select KVM_GUEST. Any kernel can be used for a guest,
and KVM/arm64 doesn't know about this configuration symbol.
OK.
Does PTP_1588_CLOCK_KVM need to default to yes?
Perhaps only on X86, to maintain the status quo?
I think I don't really understand the problem you are trying to
solve. Is it that 'make oldconfig' now asks you about this new driver?
Why is that an issue?
My first "problem" was that it asked about this new driver on
arm/arm64, while I assumed there were some missing dependencies
(configuring a kernel should not ask useless questions). That turned
out to be a wrong assumption, so there is no such problem here.
The second problem is "default y": code that is not critical should
not be enabled by default. Hence my last question.
I think consistency between architectures is important. Certainly,
distributions depend on that, and we otherwise end-up with distro
kernels missing functionalities.
The notion of "critical" is also pretty relative. defconfig contains a
gazillion of things that are not critical to most people, for example,
and yet misses a bunch of things that are needed to boot on some of my
systems.
That's just to say that I find it difficult to make that choice from
the PoV of a kernel hacker. I'm personally more inclined to leave
things enabled and let people *disable* things if they want to reduce
the footprint of their kernel.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
Why does this not depend on KVM_GUEST on ARM?
I.e. shouldn't the dependency be:
KVM_GUEST && (X86 || (HAVE_ARM_SMCCC_DISCOVERY && ARM_ARCH_TIMER))
?
arm/arm64 do not select KVM_GUEST. Any kernel can be used for a guest,
and KVM/arm64 doesn't know about this configuration symbol.
OK.
Does PTP_1588_CLOCK_KVM need to default to yes?
Perhaps only on X86, to maintain the status quo?
I think I don't really understand the problem you are trying to
solve. Is it that 'make oldconfig' now asks you about this new driver?
Why is that an issue?
My first "problem" was that it asked about this new driver on
arm/arm64, while I assumed there were some missing dependencies
(configuring a kernel should not ask useless questions). That turned
out to be a wrong assumption, so there is no such problem here.
The second problem is "default y": code that is not critical should
not be enabled by default. Hence my last question.
I think consistency between architectures is important. Certainly,
distributions depend on that, and we otherwise end-up with distro
kernels missing functionalities.
The notion of "critical" is also pretty relative. defconfig contains a
I'm not talking about defconfig, but about "default y" in defconfig.
gazillion of things that are not critical to most people, for example,
and yet misses a bunch of things that are needed to boot on some of my
systems.
Perhaps those should be added, so those systems can be tested using
defconfig? At least for arm64, I think that's aligned with the
arm64 defconfig policy.
That's just to say that I find it difficult to make that choice from
the PoV of a kernel hacker. I'm personally more inclined to leave
things enabled and let people *disable* things if they want to reduce
the footprint of their kernel.
The standard question to respond to w.r.t. "default y" is: "Why is
your feature so special that it needs to be enabled by default?",
which implies "default y" is the exception, not the rule.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds