linux-kernel - Re: [PATCH v1 3/5] virtio-mem: s390x support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240910161812-mutt-send-email-mst@kernel.org>
Date: Tue, 10 Sep 2024 16:18:26 -0400
From: "Michael S. Tsirkin" <mst@...hat.com>
To: David Hildenbrand <david@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	linux-s390@...r.kernel.org, virtualization@...ts.linux.dev,
	Heiko Carstens <hca@...ux.ibm.com>,
	Vasily Gorbik <gor@...ux.ibm.com>,
	Alexander Gordeev <agordeev@...ux.ibm.com>,
	Christian Borntraeger <borntraeger@...ux.ibm.com>,
	Sven Schnelle <svens@...ux.ibm.com>, Thomas Huth <thuth@...hat.com>,
	Cornelia Huck <cohuck@...hat.com>,
	Janosch Frank <frankja@...ux.ibm.com>,
	Claudio Imbrenda <imbrenda@...ux.ibm.com>,
	Jason Wang <jasowang@...hat.com>,
	Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
	Eugenio Pérez <eperezma@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v1 3/5] virtio-mem: s390x support

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 <david@...hat.com>


Acked-by: Michael S. Tsirkin <mst@...hat.com>


> ---
>  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