From patchwork Thu Mar 11 15:51:01 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrea Righi X-Patchwork-Id: 1451360 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4DxD2G6gffz9sWY; Fri, 12 Mar 2021 02:51:18 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1lKNal-0004gr-TR; Thu, 11 Mar 2021 15:51:15 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1lKNah-0004et-J2 for kernel-team@lists.ubuntu.com; Thu, 11 Mar 2021 15:51:11 +0000 Received: from mail-ed1-f69.google.com ([209.85.208.69]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1lKNah-0007gX-Bh for kernel-team@lists.ubuntu.com; Thu, 11 Mar 2021 15:51:11 +0000 Received: by mail-ed1-f69.google.com with SMTP id m8so4379258edv.11 for ; Thu, 11 Mar 2021 07:51:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=vqyvSFJ42apRrtbJLBHTB0QFJPBibF2dbqD/DN0WbHI=; b=TLkU8WE+E6IJ49aYp3Gdy7CIrHtotL3Z/wb9rsLIQrjGrN+fCgMa4PyAn3hIpI9JfQ 2EsyvsakhgYOSNM+QPRWr9OQ+XiXTDF067S9wnBxf9TwCi9WCyeP1AO3N9x9l07SQ5Pq d46+rN5QOsk8Cism5CuXb/2d/dAszEy73jqn8A+rYYM90VmX0oSnvoKzArg2Eo8s9/t8 GCiMakGumvFmEyJWmixMP8h1P8QQb8c2dI12jIIGB3NbiXkCmfIQ3LZzU4gnFnVvSFkU rRu270q7HiQeZwJe9Css4/I1AiAM/N4PWBzm+cDYuwMMmTQ7pATWAsxjhL5oSLfmh67S ZjuA== X-Gm-Message-State: AOAM533RuaU56crCR/FAJ4E301B6zs5vEKBuGZLZwc1cANWfRwJTFgaJ 2HvRm2adqvw5pye9KU6QqMfUvmAFWUEfyuKKHpwJOAoxyj/7CeY3R5Scs89Tdvc7c0uojg44MmA +QlnH2xTnR9cQvH4sXC4Pa5Dj2+/UW00bRYTYOCZOSQ== X-Received: by 2002:aa7:d9c8:: with SMTP id v8mr8992862eds.9.1615477871063; Thu, 11 Mar 2021 07:51:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJy0vfBRpcP4K912p0PV4caI2rg6KvMui7GhdSU9fQhW146v0E9IsRjN7nFcbRHK/XtMYUczlA== X-Received: by 2002:aa7:d9c8:: with SMTP id v8mr8992848eds.9.1615477870837; Thu, 11 Mar 2021 07:51:10 -0800 (PST) Received: from xps-13-7390.homenet.telecomitalia.it (host-95-235-132-1.retail.telecomitalia.it. [95.235.132.1]) by smtp.gmail.com with ESMTPSA id d19sm1545998edr.45.2021.03.11.07.51.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Mar 2021 07:51:10 -0800 (PST) From: Andrea Righi To: kernel-team@lists.ubuntu.com Subject: [SRU][F/aws][PATCH 2/2] UBUNTU: SAUCE: aws: kvm: double the size of hv_clock_boot Date: Thu, 11 Mar 2021 16:51:01 +0100 Message-Id: <20210311155101.98612-3-andrea.righi@canonical.com> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210311155101.98612-1-andrea.righi@canonical.com> References: <20210311155101.98612-1-andrea.righi@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" 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 --- arch/x86/kernel/kvmclock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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);