From patchwork Fri Jun 10 12:45:29 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Frank Heimes X-Patchwork-Id: 1641943 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=LGm7kpjo; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) 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 bilbo.ozlabs.org (Postfix) with ESMTPS id 4LKLKh1d6tz9s75 for ; Fri, 10 Jun 2022 22:45:44 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1nze1B-0008QT-Bk; Fri, 10 Jun 2022 12:45:37 +0000 Received: from smtp-relay-canonical-1.internal ([10.131.114.174] helo=smtp-relay-canonical-1.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1nze18-0008PU-Rz for kernel-team@lists.ubuntu.com; Fri, 10 Jun 2022 12:45:34 +0000 Received: from T570.fritz.box (p54abbc1a.dip0.t-ipconnect.de [84.171.188.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-canonical-1.canonical.com (Postfix) with ESMTPSA id DB8623FF8D for ; Fri, 10 Jun 2022 12:45:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1654865133; bh=nh/9Erv6QBMM5hfQ9BoZozpk+1m7L+Wsf2uBgrRQMkU=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=LGm7kpjocOXA63F0TAkNLi+bdKcfv/8ZFUvL8P9b6k4y92lOkm3n9Pbs/E4hwUeQx 3zGowg8B9FKOeQ1N9/R6E1IT6M66+ostmDt+O9xHGXovhlt3LHs85cwADF1QF/aLGr iZELPgzT2O6Lhpy6XtT0NQZBzmzibT+curz/B8cjTfQK+cQnmjM9g3DDvfhz3Jgo6p 4Z00cmLTeIRBxJRX2vsQ+9N3ZucZmSy3UhdrrtB6trCCdTiPrOXUnqiyglRj6cdTnf 2WzIHVh0P/Y7AB7wA23vzgyzZUqekalvFGXvi8Un7sVjKmspCtbmIK231uOKCTc57x ougtE7UF8r3Tg== From: frank.heimes@canonical.com To: kernel-team@lists.ubuntu.com Subject: [SRU][J][PATCH 1/2] s390/gmap: voluntarily schedule during key setting Date: Fri, 10 Jun 2022 14:45:29 +0200 Message-Id: <20220610124530.462651-2-frank.heimes@canonical.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220610124530.462651-1-frank.heimes@canonical.com> References: <20220610124530.462651-1-frank.heimes@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" From: Christian Borntraeger BugLink: https://bugs.launchpad.net/bugs/1975582 With large and many guest with storage keys it is possible to create large latencies or stalls during initial key setting: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 18-....: (2099 ticks this GP) idle=54e/1/0x4000000000000002 softirq=35598716/35598716 fqs=998 (t=2100 jiffies g=155867385 q=20879) Task dump for CPU 18: CPU 1/KVM R running task 0 1030947 256019 0x06000004 Call Trace: sched_show_task rcu_dump_cpu_stacks rcu_sched_clock_irq update_process_times tick_sched_handle tick_sched_timer __hrtimer_run_queues hrtimer_interrupt do_IRQ ext_int_handler ptep_zap_key The mmap lock is held during the page walking but since this is a semaphore scheduling is still possible. Same for the kvm srcu. To minimize overhead do this on every segment table entry or large page. Signed-off-by: Christian Borntraeger Reviewed-by: Alexander Gordeev Reviewed-by: Claudio Imbrenda Link: https://lore.kernel.org/r/20220530092706.11637-2-borntraeger@linux.ibm.com Signed-off-by: Christian Borntraeger Signed-off-by: Heiko Carstens (cherry picked from commit 6d5946274df1fff539a7eece458a43be733d1db8) Signed-off-by: Frank Heimes --- arch/s390/mm/gmap.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/arch/s390/mm/gmap.c b/arch/s390/mm/gmap.c index ce39bb3c4806..3241c5e34954 100644 --- a/arch/s390/mm/gmap.c +++ b/arch/s390/mm/gmap.c @@ -2608,6 +2608,18 @@ static int __s390_enable_skey_pte(pte_t *pte, unsigned long addr, return 0; } +/* + * Give a chance to schedule after setting a key to 256 pages. + * We only hold the mm lock, which is a rwsem and the kvm srcu. + * Both can sleep. + */ +static int __s390_enable_skey_pmd(pmd_t *pmd, unsigned long addr, + unsigned long next, struct mm_walk *walk) +{ + cond_resched(); + return 0; +} + static int __s390_enable_skey_hugetlb(pte_t *pte, unsigned long addr, unsigned long hmask, unsigned long next, struct mm_walk *walk) @@ -2630,12 +2642,14 @@ static int __s390_enable_skey_hugetlb(pte_t *pte, unsigned long addr, end = start + HPAGE_SIZE - 1; __storage_key_init_range(start, end); set_bit(PG_arch_1, &page->flags); + cond_resched(); return 0; } static const struct mm_walk_ops enable_skey_walk_ops = { .hugetlb_entry = __s390_enable_skey_hugetlb, .pte_entry = __s390_enable_skey_pte, + .pmd_entry = __s390_enable_skey_pmd, }; int s390_enable_skey(void) From patchwork Fri Jun 10 12:45:30 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Frank Heimes X-Patchwork-Id: 1641941 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=EDwzY1Qi; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) 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 bilbo.ozlabs.org (Postfix) with ESMTPS id 4LKLKg66BCz9s5V for ; Fri, 10 Jun 2022 22:45:43 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1nze1B-0008QB-3a; Fri, 10 Jun 2022 12:45:37 +0000 Received: from smtp-relay-canonical-1.internal ([10.131.114.174] helo=smtp-relay-canonical-1.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1nze19-0008Pg-GL for kernel-team@lists.ubuntu.com; Fri, 10 Jun 2022 12:45:35 +0000 Received: from T570.fritz.box (p54abbc1a.dip0.t-ipconnect.de [84.171.188.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-canonical-1.canonical.com (Postfix) with ESMTPSA id CAFD93F610 for ; Fri, 10 Jun 2022 12:45:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1654865134; bh=Fh11Zj35WZJiydbgjRp5f7xZzrxynW2xJWlsNmU9kys=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=EDwzY1Qiw39QGbNt2JWQNVuY60S0Be7ASTin5S6CN98Hp0FQUlgmAhnj9ztXxC++M yfIbpA9XCBygp7fl4FZvtQl2EpohUvpr56SxSbro9IQS3FJw4zESDFwhnLGCrTs1Ts ezTLO8pBe7EgFvGlrthJz7y6YIfPy0ev7JP/aJ2ff3rfBHx5nOZmaeBgamUNVMGi1A jxK1jLbFnNmoS+6LSoqcqXHkh3JAjhukmS/nI2kGlIME3KQmBHeXycHfkrzy+XElWt 2nQI6kWPzHYSBQyUenZmbKgr2WIEoisSKDnZFcfEeSFcEsL4sjxun6gb0fyct3CQan Uqma+jxz1gOKQ== From: frank.heimes@canonical.com To: kernel-team@lists.ubuntu.com Subject: [SRU][J][PATCH 2/2] s390/mm: use non-quiescing sske for KVM switch to keyed guest Date: Fri, 10 Jun 2022 14:45:30 +0200 Message-Id: <20220610124530.462651-3-frank.heimes@canonical.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220610124530.462651-1-frank.heimes@canonical.com> References: <20220610124530.462651-1-frank.heimes@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" s390/mm: use non-quiescing sske for KVM switch to keyed guest From: Christian Borntraeger The switch to a keyed guest does not require a classic sske as the other guest CPUs are not accessing the key before the switch is complete. By using the NQ SSKE things are faster especially with multiple guests. Signed-off-by: Christian Borntraeger Suggested-by: Janis Schoetterl-Glausch Reviewed-by: Claudio Imbrenda Link: https://lore.kernel.org/r/20220530092706.11637-3-borntraeger@linux.ibm.com Signed-off-by: Christian Borntraeger Signed-off-by: Heiko Carstens (cherry picked from commit 3ae11dbcfac906a8c3a480e98660a823130dc16a) Signed-off-by: Frank Heimes --- arch/s390/mm/pgtable.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c index 6ad634a27d5b..df0adb7e2fe8 100644 --- a/arch/s390/mm/pgtable.c +++ b/arch/s390/mm/pgtable.c @@ -748,7 +748,7 @@ void ptep_zap_key(struct mm_struct *mm, unsigned long addr, pte_t *ptep) pgste_val(pgste) |= PGSTE_GR_BIT | PGSTE_GC_BIT; ptev = pte_val(*ptep); if (!(ptev & _PAGE_INVALID) && (ptev & _PAGE_WRITE)) - page_set_storage_key(ptev & PAGE_MASK, PAGE_DEFAULT_KEY, 1); + page_set_storage_key(ptev & PAGE_MASK, PAGE_DEFAULT_KEY, 0); pgste_set_unlock(ptep, pgste); preempt_enable(); }