From: Heiko Carstens <hca@linux.ibm.com>
To: Alexander Gordeev <agordeev@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
David Hildenbrand <david@kernel.org>
Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH 1/4] KVM: s390: pv: Use VM_SPARSE area for guest variable storage area
Date: Thu, 16 Jul 2026 16:14:33 +0200 [thread overview]
Message-ID: <20260716141436.2125703-2-hca@linux.ibm.com> (raw)
In-Reply-To: <20260716141436.2125703-1-hca@linux.ibm.com>
The guest variable storage area is allocated with vmalloc and then
donated to the ultravisor. Any kernel access to that area will result
in a secure storage access exception (aka fault).
This is a problem if such a memory area is read via /proc/kcore. This
causes an exception via vread_iter() and results in an unexpected short
read. Avoid this by allocating a custom VM_SPARSE area. If such an area
is read, vread_iter() returns zeroes for the entire area.
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
---
arch/s390/include/asm/uv.h | 2 ++
arch/s390/kernel/uv.c | 59 ++++++++++++++++++++++++++++++++++++++
arch/s390/kvm/pv.c | 6 ++--
3 files changed, 64 insertions(+), 3 deletions(-)
diff --git a/arch/s390/include/asm/uv.h b/arch/s390/include/asm/uv.h
index d919e69662f5..153fed63adda 100644
--- a/arch/s390/include/asm/uv.h
+++ b/arch/s390/include/asm/uv.h
@@ -635,6 +635,8 @@ int s390_wiggle_split_folio(struct mm_struct *mm, struct folio *folio);
int __make_folio_secure(struct folio *folio, struct uv_cb_header *uvcb);
int uv_convert_from_secure(unsigned long paddr);
int uv_convert_from_secure_folio(struct folio *folio);
+void *uv_alloc_stor_var(unsigned long size);
+void uv_free_stor_var(void *stor_var);
void setup_uv(void);
diff --git a/arch/s390/kernel/uv.c b/arch/s390/kernel/uv.c
index a284f98d9716..98a7f988fc69 100644
--- a/arch/s390/kernel/uv.c
+++ b/arch/s390/kernel/uv.c
@@ -16,6 +16,7 @@
#include <linux/swap.h>
#include <linux/pagewalk.h>
#include <linux/backing-dev.h>
+#include <linux/vmalloc.h>
#include <asm/facility.h>
#include <asm/sections.h>
#include <asm/uv.h>
@@ -209,6 +210,64 @@ int uv_convert_from_secure_pte(pte_t pte)
return uv_convert_from_secure_folio(pfn_folio(pte_pfn(pte)));
}
+static int uv_free_range_cb(pte_t *ptep, unsigned long addr, void *data)
+{
+ pte_t pte = ptep_get(ptep);
+
+ if (!pte_present(pte))
+ return 0;
+ __free_page(pte_page(pte));
+ return 0;
+}
+
+void uv_free_stor_var(void *stor_var)
+{
+ unsigned long addr, size;
+ struct vm_struct *area;
+
+ if (!stor_var)
+ return;
+ area = find_vm_area(stor_var);
+ if (WARN_ON_ONCE(!area || !(area->flags & VM_SPARSE)))
+ return;
+ size = get_vm_area_size(area);
+ addr = (unsigned long)area->addr;
+ apply_to_existing_page_range(&init_mm, addr, size, uv_free_range_cb, NULL);
+ free_vm_area(area);
+}
+EXPORT_SYMBOL_FOR_MODULES(uv_free_stor_var, "kvm");
+
+static int uv_alloc_range_cb(pte_t *ptep, unsigned long addr, void *data)
+{
+ struct page *page;
+ pte_t pte;
+
+ page = alloc_page(GFP_KERNEL_ACCOUNT | __GFP_ZERO);
+ if (!page)
+ return -ENOMEM;
+ pte = __pte(page_to_phys(page) | pgprot_val(PAGE_KERNEL));
+ set_pte(ptep, pte);
+ return 0;
+}
+
+void *uv_alloc_stor_var(unsigned long size)
+{
+ struct vm_struct *area;
+ unsigned long addr;
+
+ area = get_vm_area(size, VM_SPARSE);
+ if (!area)
+ return NULL;
+ addr = (unsigned long)area->addr;
+ if (apply_to_page_range(&init_mm, addr, size, uv_alloc_range_cb, NULL))
+ goto out;
+ return area->addr;
+out:
+ uv_free_stor_var(area->addr);
+ return NULL;
+}
+EXPORT_SYMBOL_FOR_MODULES(uv_alloc_stor_var, "kvm");
+
/*
* Calculate the expected ref_count for a folio that would otherwise have no
* further pins. This was cribbed from similar functions in other places in
diff --git a/arch/s390/kvm/pv.c b/arch/s390/kvm/pv.c
index 1beacc841ca8..dc5ac29b4c31 100644
--- a/arch/s390/kvm/pv.c
+++ b/arch/s390/kvm/pv.c
@@ -337,7 +337,7 @@ int kvm_s390_pv_create_cpu(struct kvm_vcpu *vcpu, u16 *rc, u16 *rrc)
/* only free resources when the destroy was successful */
static void kvm_s390_pv_dealloc_vm(struct kvm *kvm)
{
- vfree(kvm->arch.pv.stor_var);
+ uv_free_stor_var(kvm->arch.pv.stor_var);
free_pages(kvm->arch.pv.stor_base,
get_order(uv_info.guest_base_stor_len));
kvm_s390_clear_pv_state(kvm);
@@ -369,7 +369,7 @@ static int kvm_s390_pv_alloc_vm(struct kvm *kvm)
/* Allocate variable storage */
vlen = ALIGN(virt * ((npages * PAGE_SIZE) / HPAGE_SIZE), PAGE_SIZE);
vlen += uv_info.guest_virt_base_stor_len;
- kvm->arch.pv.stor_var = vzalloc(vlen);
+ kvm->arch.pv.stor_var = uv_alloc_stor_var(vlen);
if (!kvm->arch.pv.stor_var)
goto out_err;
return 0;
@@ -414,7 +414,7 @@ static int kvm_s390_pv_dispose_one_leftover(struct kvm *kvm,
*/
free_pages(leftover->stor_base, get_order(uv_info.guest_base_stor_len));
free_pages(leftover->old_gmap_table, CRST_ALLOC_ORDER);
- vfree(leftover->stor_var);
+ uv_free_stor_var(leftover->stor_var);
done_fast:
atomic_dec(&kvm->mm->context.protected_count);
return 0;
--
2.53.0
next prev parent reply other threads:[~2026-07-16 14:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 14:14 [PATCH 0/4] s390: Reintroduce support for DCACHE_WORD_ACCESS Heiko Carstens
2026-07-16 14:14 ` Heiko Carstens [this message]
2026-07-16 14:33 ` [PATCH 1/4] KVM: s390: pv: Use VM_SPARSE area for guest variable storage area sashiko-bot
2026-07-16 14:14 ` [PATCH 2/4] s390/mm: Fix handling of secure storage access exceptions in vmalloc area Heiko Carstens
2026-07-16 14:14 ` [PATCH 3/4] s390/mm: Remove folio handling for secure storage access exceptions Heiko Carstens
2026-07-16 14:19 ` David Hildenbrand (Arm)
2026-07-16 14:14 ` [PATCH 4/4] s390: Add support for DCACHE_WORD_ACCESS (again) Heiko Carstens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260716141436.2125703-2-hca@linux.ibm.com \
--to=hca@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=david@kernel.org \
--cc=frankja@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=svens@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.