kernel.git/arch/s390/kernel/uv.c, branch linux-6.15.y

s390/uv: Improve splitting of large folios that cannot be split while dirty

2025-06-19T13:40:23Z

[ Upstream commit ab73b29efd36f8916c6cc9954e912c4723c9a1b0 ] Currently, starting a PV VM on an iomap-based filesystem with large folio support, such as XFS, will not work. We'll be stuck in unpack_one()->gmap_make_secure(), because we can't seem to make progress splitting the large folio. The problem is that we require a writable PTE but a writable PTE under such filesystems will imply a dirty folio. So whenever we have a writable PTE, we'll have a dirty folio, and dirty iomap folios cannot currently get split, because split_folio()->split_huge_page_to_list_to_order()->filemap_release_folio() will fail in iomap_release_folio(). So we will not make any progress splitting such large folios. Until dirty folios can be split more reliably, let's manually trigger writeback of the problematic folio using filemap_write_and_wait_range(), and retry the split immediately afterwards exactly once, before looking up the folio again. Should this logic be part of split_folio()? Likely not; most split users don't have to split so eagerly to make any progress. For now, this seems to affect xfs, zonefs and erofs, and this patch makes it work again (tested on xfs only). While this could be considered a fix for commit 6795801366da ("xfs: Support large folios"), commit df2f9708ff1f ("zonefs: enable support for large folios") and commit ce529cc25b18 ("erofs: enable large folios for iomap mode"), before commit eef88fe45ac9 ("s390/uv: Split large folios in gmap_make_secure()"), we did not try splitting large folios at all. So it's all rather part of making SE compatible with file systems that support large folios. But to have some "Fixes:" tag, let's just use eef88fe45ac9. Not CCing stable, because there are a lot of dependencies, and it simply not working is not critical in stable kernels. Reported-by: Sebastian Mitterle Closes: https://issues.redhat.com/browse/RHEL-58218 Fixes: eef88fe45ac9 ("s390/uv: Split large folios in gmap_make_secure()") Signed-off-by: David Hildenbrand Link: https://lore.kernel.org/r/20250516123946.1648026-4-david@redhat.com Message-ID: <20250516123946.1648026-4-david@redhat.com> Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Signed-off-by: Sasha Levin

s390/uv: Always return 0 from s390_wiggle_split_folio() if successful

2025-06-19T13:40:23Z

[ Upstream commit bd428b8c79ed8e8658570e70c62c0092500e2eac ] Let's consistently return 0 if the operation was successful, and just detect ourselves whether splitting is required -- folio_test_large() is a cheap operation. Update the documentation. Should we simply always return -EAGAIN instead of 0, so we don't have to handle it in the caller? Not sure, staring at the documentation, this way looks a bit cleaner. Signed-off-by: David Hildenbrand Link: https://lore.kernel.org/r/20250516123946.1648026-3-david@redhat.com Message-ID: <20250516123946.1648026-3-david@redhat.com> Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Stable-dep-of: ab73b29efd36 ("s390/uv: Improve splitting of large folios that cannot be split while dirty") Signed-off-by: Sasha Levin

s390/uv: Don't return 0 from make_hva_secure() if the operation was not successful

2025-06-19T13:40:23Z

[ Upstream commit 3ec8a8330a1aa846dffbf1d64479213366c55b54 ] If s390_wiggle_split_folio() returns 0 because splitting a large folio succeeded, we will return 0 from make_hva_secure() even though a retry is required. Return -EAGAIN in that case. Otherwise, we'll return 0 from gmap_make_secure(), and consequently from unpack_one(). In kvm_s390_pv_unpack(), we assume that unpacking succeeded and skip unpacking this page. Later on, we run into issues and fail booting the VM. So far, this issue was only observed with follow-up patches where we split large pagecache XFS folios. Maybe it can also be triggered with shmem? We'll cleanup s390_wiggle_split_folio() a bit next, to also return 0 if no split was required. Fixes: d8dfda5af0be ("KVM: s390: pv: fix race when making a page secure") Cc: stable@vger.kernel.org Signed-off-by: David Hildenbrand Link: https://lore.kernel.org/r/20250516123946.1648026-2-david@redhat.com Message-ID: <20250516123946.1648026-2-david@redhat.com> Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Stable-dep-of: ab73b29efd36 ("s390/uv: Improve splitting of large folios that cannot be split while dirty") Signed-off-by: Sasha Levin

KVM: s390: pv: fix race when making a page secure

2025-03-14T14:24:19Z

Holding the pte lock for the page that is being converted to secure is needed to avoid races. A previous commit removed the locking, which caused issues. Fix by locking the pte again. Fixes: 5cbe24350b7d ("KVM: s390: move pv gmap functions into kvm") Reported-by: David Hildenbrand Tested-by: David Hildenbrand Reviewed-by: David Hildenbrand [david@redhat.com: replace use of get_locked_pte() with folio_walk_start()] Link: https://lore.kernel.org/r/20250312184912.269414-2-imbrenda@linux.ibm.com Signed-off-by: Claudio Imbrenda Message-ID: <20250312184912.269414-2-imbrenda@linux.ibm.com>

KVM: s390: move pv gmap functions into kvm

2025-01-31T11:03:52Z

Move gmap related functions from kernel/uv into kvm. Create a new file to collect gmap-related functions. Reviewed-by: Janosch Frank Reviewed-by: Christoph Schlameuss [fixed unpack_one(), thanks mhartmay@linux.ibm.com] Link: https://lore.kernel.org/r/20250123144627.312456-6-imbrenda@linux.ibm.com Signed-off-by: Claudio Imbrenda Message-ID: <20250123144627.312456-6-imbrenda@linux.ibm.com>

s390/uv: Retrieve UV secrets sysfs support

2024-10-29T10:17:17Z

Reflect the updated content in the query information UVC to the sysfs at /sys/firmware/query * new UV-query sysfs entry for the maximum number of retrievable secrets the UV can store for one secure guest. * new UV-query sysfs entry for the maximum number of association secrets the UV can store for one secure guest. * max_secrets contains the sum of max association and max retrievable secrets. Reviewed-by: Christoph Schlameuss Signed-off-by: Steffen Eiden Link: https://lore.kernel.org/r/20241024062638.1465970-7-seiden@linux.ibm.com Signed-off-by: Janosch Frank Signed-off-by: Heiko Carstens

s390/uv: Retrieve UV secrets support

2024-10-29T10:17:16Z

Provide a kernel API to retrieve secrets from the UV secret store. Add two new functions: * `uv_get_secret_metadata` - get metadata for a given secret identifier * `uv_retrieve_secret` - get the secret value for the secret index With those two functions one can extract the secret for a given secret id, if the secret is retrievable. Reviewed-by: Christoph Schlameuss Signed-off-by: Steffen Eiden Link: https://lore.kernel.org/r/20241024084107.2418186-1-seiden@linux.ibm.com Signed-off-by: Janosch Frank Signed-off-by: Heiko Carstens

s390/uv: Provide host-key hashes in sysfs

2024-10-29T10:17:16Z

Utilize the new Query Ultravisor Keys UVC to give user space the information which host-keys are installed on the system. Create a new sysfs directory 'firmware/uv/keys' that contains the hash of the host-key and the backup host-key of that system. Additionally, the file 'all' contains the response from the UVC possibly containing more key-hashes than currently known. Reviewed-by: Janosch Frank Signed-off-by: Steffen Eiden Link: https://lore.kernel.org/r/20241023075529.2561384-1-seiden@linux.ibm.com Signed-off-by: Janosch Frank Signed-off-by: Heiko Carstens

s390/uv: Refactor uv-sysfs creation

2024-10-29T10:17:16Z

Streamline the sysfs generation to make it more extensible. Add a function to create a sysfs entry in the uv-sysfs dir. Use this function for the query directory. Reviewed-by: Janosch Frank Reviewed-by: Christoph Schlameuss Signed-off-by: Steffen Eiden Link: https://lore.kernel.org/r/20241015113940.3088249-2-seiden@linux.ibm.com Signed-off-by: Janosch Frank Signed-off-by: Heiko Carstens

s390/uv: convert gmap_destroy_page() from follow_page() to folio_walk

2024-09-02T03:26:01Z

Let's get rid of another follow_page() user and perform the UV calls under PTL -- which likely should be fine. No need for an additional reference while holding the PTL: uv_destroy_folio() and uv_convert_from_secure_folio() raise the refcount, so any concurrent make_folio_secure() would see an unexpted reference and cannot set PG_arch_1 concurrently. Do we really need a writable PTE? Likely yes, because the "destroy" part is, in comparison to the export, a destructive operation. So we'll keep the writability check for now. We'll lose the secretmem check from follow_page(). Likely we don't care about that here. Link: https://lkml.kernel.org/r/20240802155524.517137-9-david@redhat.com Signed-off-by: David Hildenbrand Reviewed-by: Claudio Imbrenda Cc: Alexander Gordeev Cc: Christian Borntraeger Cc: Gerald Schaefer Cc: Heiko Carstens Cc: Janosch Frank Cc: Jonathan Corbet Cc: Matthew Wilcox Cc: Sven Schnelle Cc: Vasily Gorbik Cc: Ryan Roberts Cc: Zi Yan Signed-off-by: Andrew Morton