From patchwork Fri Oct 25 14:14:49 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Hildenbrand X-Patchwork-Id: 13850766 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2DCC7D0C614 for ; Fri, 25 Oct 2024 14:15:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B49B66B009D; Fri, 25 Oct 2024 10:15:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AFAF06B009E; Fri, 25 Oct 2024 10:15:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 99CBC6B009F; Fri, 25 Oct 2024 10:15:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 761396B009D for ; Fri, 25 Oct 2024 10:15:42 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 28BF0AB124 for ; Fri, 25 Oct 2024 14:15:03 +0000 (UTC) X-FDA: 82712321580.20.3C23326 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 4DAF34001A for ; Fri, 25 Oct 2024 14:15:16 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=BjGBJ6lZ; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf11.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729865570; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=U+nIERtDVeS/EhO1Z1RMDJ6bPWg7jhlY/grynlrcupM=; b=op7Bti0VscP9uJXPxGXIPOCdALd/pDflysrkO5S4rc8CI7TrzHSEiy2KS72lGTcDDmv5oI 3OMVASzpC6A+7CwEU6bTh4r+WK1eiYk27vYSPPYV5FH1Ty1oNPLy7xSdb030KqlJGIoPEK 55paVkJx9Xd23gFK1WEV9BeVLFQrRxo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729865570; a=rsa-sha256; cv=none; b=AzN0jyrqHqYhR3U8AqiVoBeKIGq2QLU9YxZTNnt4229AVB4VDiPzthkC5oJIs8i4B1Ed6B 2W583eKUqphBkALANfiDefMOzttUNY1K3B6fogERgp83wF+nmeWtc8DtJM3AyCPj3ybNDx kA+WxmTUKMpoQqRlqdv0hUcWcyKsPm4= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=BjGBJ6lZ; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf11.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1729865739; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=U+nIERtDVeS/EhO1Z1RMDJ6bPWg7jhlY/grynlrcupM=; b=BjGBJ6lZztlyntSA9zEW5N+/GZf7XrS62FJVQUXGAMtc90pW/g753fhXsAqms6BTbGORQY NKIvnBQ9YTFzjwCI6c3mC8RtXaySZgt35bS713pywFps06mjD1BKbmUYocJAO55D64DsAV 9+ocV031HSO2bGnC+BC2n3ejCTafQjo= Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-659-F9VDsh4JNJadqAm0djARcA-1; Fri, 25 Oct 2024 10:15:37 -0400 X-MC-Unique: F9VDsh4JNJadqAm0djARcA-1 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (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 mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DA7941955EAA; Fri, 25 Oct 2024 14:15:34 +0000 (UTC) Received: from t14s.redhat.com (unknown [10.22.65.27]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D6E921955F39; Fri, 25 Oct 2024 14:15:26 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, linux-s390@vger.kernel.org, virtualization@lists.linux.dev, linux-doc@vger.kernel.org, kvm@vger.kernel.org, David Hildenbrand , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Thomas Huth , Cornelia Huck , Janosch Frank , Claudio Imbrenda , "Michael S. Tsirkin" , Jason Wang , Xuan Zhuo , =?utf-8?q?Eugenio_P=C3=A9rez?= , Eric Farman , Andrew Morton , Jonathan Corbet , Mario Casquero Subject: [PATCH v3 4/7] virtio-mem: s390 support Date: Fri, 25 Oct 2024 16:14:49 +0200 Message-ID: <20241025141453.1210600-5-david@redhat.com> In-Reply-To: <20241025141453.1210600-1-david@redhat.com> References: <20241025141453.1210600-1-david@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 4DAF34001A X-Stat-Signature: xxw8xa1w8mhzbcyyzjodc5ea8sp95ujg X-Rspam-User: X-HE-Tag: 1729865716-517168 X-HE-Meta: U2FsdGVkX1+xd58xIUKwpXC389p2iZP7TxxfkZQesoWOozT6TsiwoBgtg043KFdyLTHtZpB56+EO5z0+bC/nZfy1Hp3bHH/T01rBO8SZ/Ofd7tHpHN0dlbfEBjie4rVxMSM5Nhn8owKtfSFN/cBVy7u+l8FMO60jexLe3GDaiKxZ+hUoMHu5agvsVoYTeFjdSXe9My4a9c/Ax7VQNg5I4Sb8pmyhHjajSYHJ4wpUiLwlWbheEEmvNzwkv+h6OJSsndTB2dfYR7HhYkYUCWMUuDK1vwAKAFutH+f0m2gOAagdYVlD3pGSXnMXTHD9DP/wo4bnvYc51dBeabnZhEK9fqcdThlyVbPLoK54xBrfzqAi8dMhtn4cRx2Fl0L8QFg8ezCg1hX0gshexU1B11XpF6itXyka+cK+GzK4sv3ApqqE7dZtuzJYfku8mZBGPO5VSmq6Epobyf9efzYmAtMYW4ZHXpSkD4a4GM2Spou20xlSXWICW8fzcEYHTHaIMlDK119iZujeyUub4ZKRkZ/iNQLW0fy5pSyRF/uFjUFkup3P7MD8lqWOrPH4RD9fBlvgMM2oqdrp52zsOydtKonc9rGdgXsb+KPlMZ6PtGoN1UJSU4eLjaXlRkcMneKcwl8MiynKOH3/Jy62wsfFnyzM1osBjktslWKnSl/B3aZuZ7tzfd6LkzC8vD5MYiGOu/2K2/+Ms3zw3KCpHZE/eN6GWG1BwCYZ8v7fmELoIl0ZzNokAX+yZI0sqXZyOfxOBDELNw3lkNyjRFSOebtYYCaiDxlbvmTK3qCsM+ZDa2R/G1prr900kOhY5KNWs0RuFrUBk9uZ0pYeQ4WiRUw/pC49TtGas9YLOPra876SPEncPYQ//Y/dA1NUwNZtELzPFiT1cXLg6IvKIAGRjW0wKY5hJ0/L58mxXZ7Eex4brm/aH+zQj2Lu/aWvsiZJrMkvi20LcBBFxGrjsb5ABQ3ndre JgSJf/1Y yWgMlTnixMztj/VBL5Mb2QaaPNC+ci817FK2GGEpYlGOsbWoRpamK77gpmkod9MUJ5ej9OkQXhMWQGwJW+/97khYakfD5kEAuyfN27lViNbvyH70wgmv8gt6wRcQigslgH2iV5gdOQL1Sab7CP83PCHRvCOPNy4VfM2R/+9+L3tcAP/mR32f2ahuJ/6s11wHa4GsSxQDD45KLQfsTudQj3UYn9kowu5SlkH+Ci0k3vv3wW+w5x/kcdIeD9bw5VI9EspAqeDBdCTgG5NBuyDi8Oly6fZESnbywvKUWNXlHv6NKLc61nXCIs2OoTkCRSEmwVQHWzE0oFLmt6rY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Now that s390 code is prepared for memory devices that reside above the maximum storage increment exposed through SCLP, everything is in place to unlock virtio-mem support. As virtio-mem in Linux currently supports logically onlining/offlining memory in pageblock granularity, we have an effective hot(un)plug granularity of 1 MiB on s390. As virito-mem adds/removes individual Linux memory blocks (256MB), we will currently never use gigantic pages in the identity mapping. It is worth noting that neither storage keys nor storage attributes (e.g., data / nodat) are touched when onlining memory blocks, which is good because we are not supposed to touch these parts for unplugged device blocks that are logically offline in Linux. We will currently never initialize storage keys for virtio-mem memory -- IOW, storage_key_init_range() is never called. It could be added in the future when plugging device blocks. But as that function essentially does nothing without modifying the code (changing PAGE_DEFAULT_ACC), that's just fine for now. kexec should work as intended and just like on other architectures that support virtio-mem: we will never place kexec binaries on virtio-mem memory, and never indicate virtio-mem memory to the 2nd kernel. The device driver in the 2nd kernel can simply reset the device -- turning all memory unplugged, to then start plugging memory and adding them to Linux, without causing trouble because the memory is already used elsewhere. The special s390 kdump mode, whereby the 2nd kernel creates the ELF core header, won't currently dump virtio-mem memory. The virtio-mem driver has a special kdump mode, from where we can detect memory ranges to dump. Based on this, support for dumping virtio-mem memory can be added in the future fairly easily. Acked-by: Michael S. Tsirkin Tested-by: Mario Casquero Signed-off-by: David Hildenbrand Acked-by: Heiko Carstens --- drivers/virtio/Kconfig | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig index 42a48ac763ee..2eb747311bfd 100644 --- a/drivers/virtio/Kconfig +++ b/drivers/virtio/Kconfig @@ -122,7 +122,7 @@ config VIRTIO_BALLOON config VIRTIO_MEM tristate "Virtio mem driver" - depends on X86_64 || ARM64 || RISCV + depends on X86_64 || ARM64 || RISCV || S390 depends on VIRTIO depends on MEMORY_HOTPLUG depends on MEMORY_HOTREMOVE @@ -132,11 +132,11 @@ config VIRTIO_MEM This driver provides access to virtio-mem paravirtualized memory devices, allowing to hotplug and hotunplug memory. - This driver currently only supports x86-64 and arm64. Although it - should compile on other architectures that implement memory - hot(un)plug, architecture-specific and/or common - code changes may be required for virtio-mem, kdump and kexec to work as - expected. + This driver currently supports x86-64, arm64, riscv and s390. + Although it should compile on other architectures that implement + memory hot(un)plug, architecture-specific and/or common + code changes may be required for virtio-mem, kdump and kexec to + work as expected. If unsure, say M.