From mboxrd@z Thu Jan 1 00:00:00 1970 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 B3D99EDE9B4 for ; Tue, 10 Sep 2024 20:18:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 230588D00BE; Tue, 10 Sep 2024 16:18:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E03A8D0056; Tue, 10 Sep 2024 16:18:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A7258D00BE; Tue, 10 Sep 2024 16:18:41 -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 E18648D0056 for ; Tue, 10 Sep 2024 16:18:40 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 917A71A0A33 for ; Tue, 10 Sep 2024 20:18:40 +0000 (UTC) X-FDA: 82549941600.11.9CC1060 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf18.hostedemail.com (Postfix) with ESMTP id 2D02B1C0004 for ; Tue, 10 Sep 2024 20:18:38 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="SNfpT3y/"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf18.hostedemail.com: domain of mst@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=mst@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725999442; a=rsa-sha256; cv=none; b=ofPVdTfP7/KceQ9MwQOpu/TP+4PjaaBQ9vkhk7LDY1R+fVoPax6f+kj2YngMmBvPdngviT +TBETJW4ItGbWbboLt9uzA2byEjrkKHI+2rjdkU5TET21XKzpwsfKhxGUNY0CFSIN9D3DW JR/lse5VfvzqSJ3EtT3GMsDeGpR/80g= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="SNfpT3y/"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf18.hostedemail.com: domain of mst@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=mst@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725999442; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=R98WPsv5DcjO+2fj601F0xB34R9dMYvuHz2AKaHWeKU=; b=c2LA9KStvRVyHv3sC+1GvEkotGZG53CkgPPu6xWym0pJK/Fnz7RyTUNaAxLvRX5mrwjHyZ htHO2amALCWB1SBlvsYcjj4/3mAPO+OlksPJDpmYLZ3n4hcZYj30EVlku8yXuASF7JUhSe alOma/a/zba9FvSmCcHbydxirtfEe2c= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1725999517; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=R98WPsv5DcjO+2fj601F0xB34R9dMYvuHz2AKaHWeKU=; b=SNfpT3y/68IX2T1YAnYKTBAG2j3mZIwtrOlXbiB15KTN1//3uYU1s1/zfi/Bn/LQ2NF4sY HU1XcztT6BeGYeYmWTFOetl+p8GEePj4SZ2Bxu5vtHIZfpYDdbLlpo99uSQOSXQWzzG3xH nmkCSByEvluOcB1L/nhgy64MCraZeqI= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-460-rnWzYaqhMx6J--SBIGNyPA-1; Tue, 10 Sep 2024 16:18:36 -0400 X-MC-Unique: rnWzYaqhMx6J--SBIGNyPA-1 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-a8d1a00e0beso22917866b.0 for ; Tue, 10 Sep 2024 13:18:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725999514; x=1726604314; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=R98WPsv5DcjO+2fj601F0xB34R9dMYvuHz2AKaHWeKU=; b=JVwbjqEeQ+fBE0PxcVK0Jls8DcOyHPlwF3VZGMzGDwCmpy/Kz1YDSntsVk0cDKAtR0 j5+5McwhGXzlhNbRS7esbukdnpSbdUr2Q86kG4KYIZ+Rx33QcJvxzaXHGs2e21vtmlt7 d8LdMnSuMDRm19ivVs89tYvT2vUsH3uNvYdPl+ibWuc/fUSDuz8Ge8qZMTNkxD582l2T HdEVatNpOVOInOhH4hrxZbQ/8YI+m+6h5ED/LnLVpp1Kc4WIleDPfNVutKz8W92g9bWu pwrKEcRjshko69lYoRaimgwszBYIdwKkoAaT1hhsZA8BVSoWph48qXf8+pzCGLWjDJAe U2aQ== X-Forwarded-Encrypted: i=1; AJvYcCX8XqZ7C3r8x7q84tUKwm/yW7IdZf0K+WhjU8joplsgeCWQQMiJJ6RXvzxYQPB66YnF8rEwOPAGMA==@kvack.org X-Gm-Message-State: AOJu0YxSXqekcldxc1o3VsUqJd+PGHCv1eKqNVtU63AWng3x+vUp+EOk y4tGY9XoWWV5dBo7cEfSTYqyFGu/5mexxwC9k/eTuUvs62uzF5mO8PMHLL/iXbc9uW0xkMStK9A gXIkiNUq2J/sed2xDogTzUXFClddp17/y0asSggPzbZyH37tCzrt098E5 X-Received: by 2002:a17:907:d1a:b0:a8a:6bd8:b671 with SMTP id a640c23a62f3a-a8ffaac08abmr220660266b.5.1725999514330; Tue, 10 Sep 2024 13:18:34 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFq5fbQ6BGaMv0cPkfGuaqAVwF+zGrA7/gctX0lOfIlCyL/ruUfB8xmIoU+UhSiCOfTzEqhiA== X-Received: by 2002:a17:907:d1a:b0:a8a:6bd8:b671 with SMTP id a640c23a62f3a-a8ffaac08abmr220656666b.5.1725999513633; Tue, 10 Sep 2024 13:18:33 -0700 (PDT) Received: from redhat.com ([2a02:14f:176:f5ce:2d9:5bfa:9916:aa0a]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a8d25d5da53sm518761066b.209.2024.09.10.13.18.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Sep 2024 13:18:32 -0700 (PDT) Date: Tue, 10 Sep 2024 16:18:26 -0400 From: "Michael S. Tsirkin" To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-s390@vger.kernel.org, virtualization@lists.linux.dev, Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Thomas Huth , Cornelia Huck , Janosch Frank , Claudio Imbrenda , Jason Wang , Xuan Zhuo , Eugenio =?iso-8859-1?Q?P=E9rez?= , Andrew Morton Subject: Re: [PATCH v1 3/5] virtio-mem: s390x support Message-ID: <20240910161812-mutt-send-email-mst@kernel.org> References: <20240910191541.2179655-1-david@redhat.com> <20240910191541.2179655-4-david@redhat.com> MIME-Version: 1.0 In-Reply-To: <20240910191541.2179655-4-david@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 2D02B1C0004 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: xsikpsd7a6nm1j5nwtcesqtks6pxe84b X-HE-Tag: 1725999518-73244 X-HE-Meta: U2FsdGVkX18olkpmcBt4ZkjaC8RlLcwFMvMrKbS2cF0aerQ3dX/zhxkMpjcu367J/QPurX5FttMDAu8pdPH5gefnrJbqECQQnbvK2K+unHK9s7S4+Re7kBGpQqo9c9KlOTZjIXjGQKr42tI841jathbF58hbTCra1VMaiNQe+kM98XYc9+GR4a3mmR5+hmrpAEpEdeu/yrnYOs15n/eoDnj2eLvMM+I1HyvOnW9S+Zz2marSBjot1c/qWqshVtyEkwMToJLoWCHXjuGoRftdkoMfmWmbyCQvxr7uqLYKZET9bw+PBoKrPv1sFS6kSmUt748dqjEd7N+UHWZxWLxn68oRnZKsVwbs6pqUj44nNgD0CFjHHu6brXg1eatmaoUpbrJ6lQ3MfzOCkjUjkHp1e/8jcHpOnXJaDPGxHM3XYP75TJTCiMFVoov2iYNiiyLLcfVyA7M3vnYfiwhDS/Q933yCX0xEHN+Sl+ddsPO6ub4dufv5rIl5dCAadQdqG6wENdTzpX5fF1/Wgu+776TUGl2MxHkWLudI3UYgr78POvs7K/MXs47Kgd59E3bVbgmdXZCrGjq1ENAqFldqKjhcgAF2z89bVSPLrRCU7zgl4CeBh4ugv8T3DVvVI7+tT9WVausM6zZe8JKtksAVERsRnvt1/TdY+cp+R7GXgIQ5rSAMxzfYyx0jBMBZoPh2sJikgxGfu4YIXUkZM/7Dt/OnBkvb6dvVuuBty/vNl4bKpi0/TuiuHrUvBZTAcQf4A3cwDzucPtH0JLqRh4Llw2qamblIvE6UDo7H6pwm4fsFZa32a+ALEDIKX7aL2dkR5rRna94CrmJ56I51GX7O8RjvvJwGBrurHLJCnSQsudt96zahvMq8XWmZBZNdbFQsgNJvST11NDTjNxPKK8ClJlKWwWRz5K3pY5yIMWQ8PuE8fXr4Xdh9pX+NigsUmanTLXoF0I5GXOJTE64VErh4nVQ 7P8mlLBK EDig1yYcu4+lyMyURvFL+H+ztJiqr1op6PpwMnlSI8tJ7Xj+TPXkgcypfvT5GTMjUA3aQ7N4aKBNOi/hCpdOUFU7aqWEX80eEg6h+7TY8PLguRNp7sp/mlUYk9xqpmgRJ16jbkonO2wUOvNItPpP//Wn40wG0IcUcnJd9pH4P2JTKPy6rbSa849UpdyDdU7vr04IGj6pUVy69crYdwz1z8GOGvsZzYUmg2/OXFTXjE1+zHUUPk/Q1aV8/y7Y2xY5SQt8WlLBKqWviVTdpQDi2rcpPVhNxtsMmqu9A/ejq6jV6lzm58gyv0+xr4xUW6LPuNkMbvcmKafPniGo= 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: On Tue, Sep 10, 2024 at 09:15:37PM +0200, David Hildenbrand wrote: > Now that s390x 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 s390x. > > 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 s390x 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. > > Signed-off-by: David Hildenbrand Acked-by: Michael S. Tsirkin > --- > drivers/virtio/Kconfig | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig > index 42a48ac763ee..fb320eea70fe 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 s390x. > + 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. > > -- > 2.46.0