Message ID | 20210311155101.98612-3-andrea.righi@canonical.com |
---|---|
State | New |
Headers | show |
Series | aws: fix hibernation issues on c5.18xlarge | expand |
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c index 904494b924c1..4466df2b0fed 100644 --- a/arch/x86/kernel/kvmclock.c +++ b/arch/x86/kernel/kvmclock.c @@ -46,7 +46,7 @@ early_param("no-kvmclock-vsyscall", parse_no_kvmclock_vsyscall); /* Aligned to page sizes to match whats mapped via vsyscalls to userspace */ #define HV_CLOCK_SIZE (sizeof(struct pvclock_vsyscall_time_info) * NR_CPUS) #define HVC_BOOT_ARRAY_SIZE \ - (PAGE_SIZE / sizeof(struct pvclock_vsyscall_time_info)) + ((PAGE_SIZE * 2)/ sizeof(struct pvclock_vsyscall_time_info)) static struct pvclock_vsyscall_time_info hv_clock_boot[HVC_BOOT_ARRAY_SIZE] __bss_decrypted __aligned(PAGE_SIZE);
BugLink: https://bugs.launchpad.net/bugs/1918694 Large KVM instance types (in particular c5.18xlarge) can experience failures when resuming from hibernation, in particular the system gets stuck immediately after the hibernated kernel is resumed (more exactly when the resume callbacks are executed). The failure seems to be related to the KVM paravirtual clock driver and a reliable workaround is to double the size of HVC_BOOT_ARRAY_SIZE. NOTE: Amazon is currently working on a proper fix that would allow to allocate hv_clock_boot dynamicall, for now doubling the size of this array seems to prevent the issue from happening. Signed-off-by: Andrea Righi <andrea.righi@canonical.com> --- arch/x86/kernel/kvmclock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)