s390/mm: Batch PTE updates in lazy MMU mode

arch/s390/kernel/setup.c +1 -0

@@ -77,6 +77,7 @@
 #include <asm/maccess.h>
 #include <asm/uv.h>
 #include <asm/asm-offsets.h>
+#include <asm/lazy_mmu.h>
 #include "entry.h"
 
 /*

arch/s390/kernel/smp.c +6 -0

@@ -59,6 +59,7 @@
 #include <asm/topology.h>
 #include <asm/vdso.h>
 #include <asm/maccess.h>
+#include <asm/lazy_mmu.h>
 #include "entry.h"
 
 enum {

@@ -866,6 +867,11 @@ int __cpu_up(unsigned int cpu, struct task_struct *tidle)
 	rc = pcpu_alloc_lowcore(pcpu, cpu);
 	if (rc)
 		return rc;
+	rc = lazy_mmu_online_cpu(GFP_KERNEL, cpu);
+	if (rc) {
+		pcpu_free_lowcore(pcpu, cpu);
+		return rc;
+	}
 	/*
 	 * Make sure global control register contents do not change
 	 * until new CPU has initialized control registers.

arch/s390/kernel/smp.c +4 -0

+static void leave_ipte_range(void)
+{
+	pte_t *ptep, *start, *start_cache, *cache;
+	unsigned long start_addr, addr;

arch/s390/include/asm/lowcore.h struct lowcore { · line 166

Quoted 10 lines · Alexander Gordeev

arch/s390/include/asm/lowcore.h +1 -1

index 3b3ecc647993..dba236664da9 100644
@@ -163,7 +163,7 @@ struct lowcore {
 	__s32	preempt_count;			/* 0x03a8 */
 	__u32	spinlock_lockval;		/* 0x03ac */
 	__u32	spinlock_index;			/* 0x03b0 */
-	__u8	pad_0x03b4[0x03b8-0x03b4];	/* 0x03b4 */
+	__s32	lazy_mmu_count;			/* 0x03b4 */

Why is this signed? Can it get negative?

arch/s390/include/asm/lowcore.h struct lowcore {

Quoted 6 lines

arch/s390/include/asm/lowcore.h +6 -0

+static __always_inline bool is_lazy_mmu_active(void)
+{
+	if (__is_defined(__DECOMPRESSOR))
+		return false;
+	if (!get_lowcore()->lazy_mmu_count)
+		return false;

I guess there is opportunity to generate better code here using an alternative and using a flag output constraint too.

Quoted 12 lines

arch/s390/kernel/setup.c +1 -0

@@ -77,6 +77,7 @@
 #include <asm/maccess.h>
 #include <asm/uv.h>
 #include <asm/asm-offsets.h>
+#include <asm/lazy_mmu.h>
 #include "entry.h"
 
 /*

@@ -1012,5 +1013,6 @@ void __init setup_arch(char **cmdline_p)
 

arch/s390/kernel/setup.c void __init setup_arch(char **cmdline_p) · line 1018

Quoted 5 lines

arch/s390/kernel/setup.c +1 -0

 void __init arch_cpu_finalize_init(void)
 {
+	lazy_mmu_online_boot_cpu();
 	sclp_init();
 }

What makes this code so special that an explicit call from arch_cpu_finalize_init() is required? This is really the last resort if everything else fails. To me it looks like the code can be changed to use a new static key, and add a generic early (pre-smp) initcall to allocate memory for cpu 0, and if that succeeds enable the static key.

Quoted 22 lines

arch/s390/kernel/smp.c +6 -0

@@ -59,6 +59,7 @@
 #include <asm/topology.h>
 #include <asm/vdso.h>
 #include <asm/maccess.h>
+#include <asm/lazy_mmu.h>
 #include "entry.h"
 
 enum {

@@ -866,6 +867,11 @@ int __cpu_up(unsigned int cpu, struct task_struct *tidle)
 	rc = pcpu_alloc_lowcore(pcpu, cpu);
 	if (rc)
 		return rc;
+	rc = lazy_mmu_online_cpu(GFP_KERNEL, cpu);
+	if (rc) {
+		pcpu_free_lowcore(pcpu, cpu);
+		return rc;
+	}
 	/*
 	 * Make sure global control register contents do not change
 	 * until new CPU has initialized control registers.

arch/s390/kernel/smp.c void __cpu_die(unsigned int cpu) · line 930

Quoted 5 lines

arch/s390/kernel/smp.c +1 -0

@@ -921,6 +927,7 @@ void __cpu_die(unsigned int cpu)
 	pcpu = per_cpu_ptr(&pcpu_devices, cpu);
 	while (!pcpu_stopped(pcpu))
 		cpu_relax();
+	lazy_mmu_offline_cpu(cpu);

Same here: what makes this code so special that this needs to be open-coded into the low level cpu hotplug code? Everybody who needs to change this

code in future will wonder why the mmu code is so special that it needs to be directly handled here, and then needs to understand the mmu code. And the answer is: there is no reason.

Please use a generic cpu hotplug notifier to avoid that maintenance get's more expensive.

Quoted 9 lines

arch/s390/kernel/smp.c +9 -0

+static void leave_ipte_range(void)
+{
+	pte_t *ptep, *start, *start_cache, *cache;
+	unsigned long start_addr, addr;
+	struct ipte_range *range;
+	int start_idx;
+
+	if (!test_facility(13))
+		return;

arch/s390/kernel/smp.c

Quoted 5 lines

arch/s390/kernel/smp.c +5 -0

+
+	local_bh_disable();
+
+	lockdep_assert_preemption_disabled();
+	range = this_cpu_read(ipte_range);

Why is it required to disable bottom halves? A comment would be helpful. Or a hint in the commit message - this is not obvious.

Also at least for !PREEMPT_RT (which is always true for s390) lockdep_assert_preemption_disabled() is quite pointless, since local_bh_disable() just one line above disables preemption.

I guess you wanted to add that check above local_bh_disable()?

If not you could as well remove it

Quoted 13 lines · Heiko Carstens

arch/s390/include/asm/lowcore.h struct lowcore { · line 166

Quoted 10 lines · Alexander Gordeev

arch/s390/include/asm/lowcore.h +1 -1

index 3b3ecc647993..dba236664da9 100644
@@ -163,7 +163,7 @@ struct lowcore {
 	__s32	preempt_count;			/* 0x03a8 */
 	__u32	spinlock_lockval;		/* 0x03ac */
 	__u32	spinlock_index;			/* 0x03b0 */
-	__u8	pad_0x03b4[0x03b8-0x03b4];	/* 0x03b4 */
+	__s32	lazy_mmu_count;			/* 0x03b4 */

Why is this signed? Can it get negative?

For the same reason preempt_count is signed, I guess.

No, it can not get negative and it is very handy to observe a disbalance in a crash (I did hit it indeed while debugging).

Quoted 9 lines

arch/s390/include/asm/lowcore.h struct lowcore {

Quoted 6 lines

arch/s390/include/asm/lowcore.h +6 -0

+static __always_inline bool is_lazy_mmu_active(void)
+{
+	if (__is_defined(__DECOMPRESSOR))
+		return false;
+	if (!get_lowcore()->lazy_mmu_count)
+		return false;

I guess there is opportunity to generate better code here using an alternative and using a flag output constraint too.

Will try.

Quoted 11 lines

arch/s390/include/asm/lowcore.h

Quoted 5 lines

void __init arch_cpu_finalize_init(void)
{

arch/s390/include/asm/lowcore.h +1 -0

+	lazy_mmu_online_boot_cpu();
 	sclp_init();
 }

What makes this code so special that an explicit call from arch_cpu_finalize_init() is required? This is really the last resort if everything else fails. To me it looks like the code can be changed to use a new static key, and add a generic early (pre-smp) initcall to allocate memory for cpu 0, and if that succeeds enable the static key.

I had exactly similar variant, but failed to resolve a race when a secondary CPU callback was called before the CPU0's one. Probably, used a wrong event. Will look into it again.

Quoted 7 lines

arch/s390/include/asm/lowcore.h

Quoted 4 lines

arch/s390/include/asm/lowcore.h +4 -0

+	local_bh_disable();
+
+	lockdep_assert_preemption_disabled();
+	range = this_cpu_read(ipte_range);

Why is it required to disable bottom halves? A comment would be helpful. Or a hint in the commit message - this is not obvious.

When an interrupt arrives in the middle of enter|leave_ipte_range() the chain pcpu_addr_to_page() -> vmalloc_to_page() -> ptep_get() decides ptep_get() is called in lazy mode, while the per-cpu state not yet (de-)initialized (AKA inconsistent). That led to crashes:

Quoted 15 lines · Alexander Gordeev

Quoted 13 lines · Heiko Carstens

arch/s390/include/asm/lowcore.h struct lowcore { · line 166

Quoted 10 lines · Alexander Gordeev

arch/s390/include/asm/lowcore.h +1 -1

index 3b3ecc647993..dba236664da9 100644
@@ -163,7 +163,7 @@ struct lowcore {
 	__s32	preempt_count;			/* 0x03a8 */
 	__u32	spinlock_lockval;		/* 0x03ac */
 	__u32	spinlock_index;			/* 0x03b0 */
-	__u8	pad_0x03b4[0x03b8-0x03b4];	/* 0x03b4 */
+	__s32	lazy_mmu_count;			/* 0x03b4 */

Why is this signed? Can it get negative?

Quoted 1 line

For the same reason preempt_count is signed, I guess.

Check again, preempt_count is now unsigned and 64 bit ;)

Quoted 12 lines

Quoted 11 lines

arch/s390/include/asm/lowcore.h struct lowcore {

Quoted 5 lines

arch/s390/include/asm/lowcore.h +1 -0

 void __init arch_cpu_finalize_init(void)
 {
+	lazy_mmu_online_boot_cpu();
 	sclp_init();
 }

What makes this code so special that an explicit call from arch_cpu_finalize_init() is required? This is really the last resort if everything else fails. To me it looks like the code can be changed to use a new static key, and add a generic early (pre-smp) initcall to allocate memory for cpu 0, and if that succeeds enable the static key.

Quoted 3 lines

I had exactly similar variant, but failed to resolve a race when a secondary CPU callback was called before the CPU0's one. Probably, used a wrong event. Will look into it again.

early_initcall() should do the trick.

Quoted 8 lines

Quoted 7 lines

arch/s390/include/asm/lowcore.h

Quoted 4 lines

arch/s390/include/asm/lowcore.h +4 -0

+	local_bh_disable();
+
+	lockdep_assert_preemption_disabled();
+	range = this_cpu_read(ipte_range);

Why is it required to disable bottom halves? A comment would be helpful. Or a hint in the commit message - this is not obvious.

Quoted 4 lines

When an interrupt arrives in the middle of enter|leave_ipte_range() the chain pcpu_addr_to_page() -> vmalloc_to_page() -> ptep_get() decides ptep_get() is called in lazy mode, while the per-cpu state not yet (de-)initialized (AKA inconsistent). That led to crashes:

So, I don't know what exactly lead to the crash, but I guess the problem is an only partially initialized ipte_range struct, while the lazy_mmu_count has been incremented already? Isn't it possible to

solve that problem without disabling bottom halves by reordering sequences in enter_ipte_range() and leave_ipte_range()?

Would be nice if we could avoid the not so obvious local_bh_disable() and local_bh_enable() pairs.

Quoted 2 lines · Heiko Carstens

Would be nice if we could avoid the not so obvious local_bh_disable() and local_bh_enable() pairs.

Calling ptep_get() from BH context was certainly unexpected, but the way local_bh_enable|disable() pairs are used is actually straightforward. This is a slow path anyway, so I would think the simplicity prevails in this case.

But again, I will try to avoid that.

Quoted 9 lines · Alexander Gordeev

Quoted 2 lines · Heiko Carstens

Would be nice if we could avoid the not so obvious local_bh_disable() and local_bh_enable() pairs.

Calling ptep_get() from BH context was certainly unexpected, but the way local_bh_enable|disable() pairs are used is actually straightforward. This is a slow path anyway, so I would think the simplicity prevails in this case.

Quoted 1 line

But again, I will try to avoid that.

I do agree that ptep_get() being called from BH context is not what I would have expected too. But then again, nothing prevents people from doing that from irq context too, no matter if that is sane or not.

Imho the "final" version should either be implemented that it can go without disabling bottom halves, or, if that is not worth the effort, even disable interrupts, just to avoid other surprises.

Plus a comment why it is needed, please.

Quoted 12 lines · Heiko Carstens

Quoted 10 lines · Alexander Gordeev

Quoted 2 lines · Heiko Carstens

Would be nice if we could avoid the not so obvious local_bh_disable() and local_bh_enable() pairs.

Calling ptep_get() from BH context was certainly unexpected, but the way local_bh_enable|disable() pairs are used is actually straightforward. This is a slow path anyway, so I would think the simplicity prevails in this case.

But again, I will try to avoid that.

Quoted 3 lines

I do agree that ptep_get() being called from BH context is not what I would have expected too. But then again, nothing prevents people from doing that from irq context too, no matter if that is sane or not.

I am currently looking if any interrupt handler does such a crazy thing. If not, I hope it would be possible to nail this requirement with the maintainers and e.g. add VM_BUG_ON(in_hardirq()) to ptep_get()/set_pte() implementations.

But even with BHs we have an interesting situation: calling ptep_get() from a BH while in the lazy MMU mode is actually a read hazard. IOW what I hit looks to me as a bug in generic code, and one that looks very difficult to fix. So staying with local_bh_enable|disable() would be still a good tradeoff.

Quoted 3 lines

Imho the "final" version should either be implemented that it can go without disabling bottom halves, or, if that is not worth the effort, even disable interrupts, just to avoid other surprises.

Yes, that would be the last resort.

Quoted 5 lines · Alexander Gordeev

Quoted 3 lines · Heiko Carstens

Imho the "final" version should either be implemented that it can go without disabling bottom halves, or, if that is not worth the effort, even disable interrupts, just to avoid other surprises.

Quoted 1 line

Yes, that would be the last resort.

So leaving local_bh_enable|disable() while adding VM_BUG_ON(in_hardirq()) could actually work.

Also, I do not see how the code could be rearranged to avoid BH disable.

arch/s390/include/asm/pgtable.h enum { · line 55

Quoted 6 lines

arch/s390/include/asm/pgtable.h +6 -0

+static __always_inline bool is_lazy_mmu_active(void)
+{
+	if (__is_defined(__DECOMPRESSOR))
+		return false;
+	if (!get_lowcore()->lazy_mmu_count)
+		return false;

I guess there is opportunity to generate better code here using an alternative and using a flag output constraint too.

Quoted 9 lines · Heiko Carstens

arch/s390/include/asm/pgtable.h enum { · line 55

Quoted 6 lines

arch/s390/include/asm/pgtable.h +6 -0

+static __always_inline bool is_lazy_mmu_active(void)
+{
+	if (__is_defined(__DECOMPRESSOR))
+		return false;
+	if (!get_lowcore()->lazy_mmu_count)
+		return false;

I guess there is opportunity to generate better code here using an alternative and using a flag output constraint too.

It is only CY and LT instructions that make sense for me. Here is what I came up with:

As result instead of gcc code:

	lghi	%r8,0
	lt	%r1,1032(%r8)
	je	...

We get more or less the same:

	lhi	%r1,0
	cy	%r1,1032
	jne	...

The only benefit is [zero] "d" (0) could sometimes avoid LHI if a zeroed register is already around. But also the KASAN coverage is not generated.

Does it make sense to go ahead whith the alternative?

Quoted 13 lines · Alexander Gordeev

Quoted 9 lines · Heiko Carstens

arch/s390/include/asm/pgtable.h enum { · line 55

Quoted 6 lines

arch/s390/include/asm/pgtable.h +6 -0

+static __always_inline bool is_lazy_mmu_active(void)
+{
+	if (__is_defined(__DECOMPRESSOR))
+		return false;
+	if (!get_lowcore()->lazy_mmu_count)
+		return false;

I guess there is opportunity to generate better code here using an alternative and using a flag output constraint too.

It is only CY and LT instructions that make sense for me. Here is what I came up with:

...

Quoted 16 lines

As result instead of gcc code:

	lghi	%r8,0
	lt	%r1,1032(%r8)
	je	...

We get more or less the same:

	lhi	%r1,0
	cy	%r1,1032
	jne	...

The only benefit is [zero] "d" (0) could sometimes avoid LHI if a zeroed register is already around. But also the KASAN coverage is not generated.

Quoted 1 line

Does it make sense to go ahead whith the alternative?

Not really. But why is lazy_mmu_count 32 bit? Do you expect a nesting level of 2^32? :) If you would reduce that to one byte you could use tmy or cliy.

Quoted 5 lines · Heiko Carstens

Quoted 1 line · Alexander Gordeev

On Mon, Aug 24, 2026 at 12:40:48PM +0200, Heiko Carstens wrote:

Not really. But why is lazy_mmu_count 32 bit? Do you expect a nesting level of 2^32? :) If you would reduce that to one byte you could use tmy or cliy.

Good point. But still, do you think it worth dropping the KASAN check?

Quoted 7 lines · Alexander Gordeev

Quoted 5 lines · Heiko Carstens

Quoted 1 line · Alexander Gordeev

On Mon, Aug 24, 2026 at 12:40:48PM +0200, Heiko Carstens wrote:

Not really. But why is lazy_mmu_count 32 bit? Do you expect a nesting level of 2^32? :) If you would reduce that to one byte you could use tmy or cliy.

Quoted 1 line

Good point. But still, do you think it worth dropping the KASAN check?

KASAN check for lowcore? I don't think we care - this is initialized to zero anyway, so what could go wrong? Also given how frequently these operations are used, yes, please drop KASAN checks.

Quoted 5 lines

Quoted 1 line

Good point. But still, do you think it worth dropping the KASAN check?

KASAN check for lowcore? I don't think we care - this is initialized to zero anyway, so what could go wrong? Also given how frequently these operations are used, yes, please drop KASAN checks.

Of course you could still add an explicit KASAN/KCSAN check by adding an instrument_read() call (see e.g. s390's fpu-insn.h, which has plenty of them).

But why do you think that would be helpful for a lowcore field, where it is known that is initialized to zero? What am I missing?

Provide helpers that allow architectures implement illegitimate PTE direct accesses while the lazy MMU mode is enabled, such as:

        pte_t pte = *ptep;
        *ptep = pte;

By contrast, these would have to be:

        pte_t pte = ptep_get(ptep);
        set_pte(ptep, pte);

The direct PTE accesses pose a real issue on s390.

Suggested-by Ilya Leoshkevich <[email protected]>

Signed-off-by Alexander Gordeev <[email protected]>

---
 include/linux/kasan.h     | 19 +++++++++++++++++--
 mm/kasan/common.c         | 14 ++++++++++++++
 mm/kasan/kasan.h          |  2 ++
 mm/kasan/report_generic.c |  3 +++
 4 files changed, 36 insertions(+), 2 deletions(-)

include/linux/kasan.h +17 -2

index bf233bde68c7..1aa4d9dd2485 100644
@@ -6,6 +6,7 @@
 #include <linux/kasan-enabled.h>
 #include <linux/kasan-tags.h>
 #include <linux/kernel.h>
+#include <linux/pgtable.h>
 #include <linux/static_key.h>
 #include <linux/types.h>
 

@@ -35,8 +36,6 @@ typedef unsigned int __bitwise kasan_vmalloc_flags_t;
 
 #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 
-#include <linux/pgtable.h>
-
 /* Software KASAN implementations use shadow memory. */
 
 #ifdef CONFIG_KASAN_SW_TAGS

@@ -134,6 +133,20 @@ static __always_inline void kasan_poison_slab(struct slab *slab)
                __kasan_poison_slab(slab);
 }
 
+void __kasan_poison_pte(pte_t *pte, int nr);
+static __always_inline void kasan_poison_pte(pte_t *pte, int nr)
+{
+       if (kasan_enabled())
+               __kasan_poison_pte(pte, nr);
+}
+
+void __kasan_unpoison_pte(pte_t *pte, int nr);
+static __always_inline void kasan_unpoison_pte(pte_t *pte, int nr)
+{
+       if (kasan_enabled())
+               __kasan_unpoison_pte(pte, nr);
+}
+
 void __kasan_unpoison_new_object(struct kmem_cache *cache, void *object);
 /**
  * kasan_unpoison_new_object - Temporarily unpoison a new slab object.

@@ -414,6 +427,8 @@ static inline bool kasan_unpoison_pages(struct page *page, unsigned int order,
        return false;
 }
 static inline void kasan_poison_slab(struct slab *slab) {}
+static inline void kasan_poison_pte(pte_t *pte, int nr) {}
+static inline void kasan_unpoison_pte(pte_t *pte, int nr) {}
 static inline void kasan_unpoison_new_object(struct kmem_cache *cache,
                                        void *object) {}
 static inline void kasan_poison_new_object(struct kmem_cache *cache,

mm/kasan/common.c +14 -0

index b7d05c2a6d93..94d106094989 100644
@@ -163,6 +163,20 @@ void __kasan_poison_slab(struct slab *slab)
                     KASAN_SLAB_REDZONE, false);
 }
 
+void __kasan_poison_pte(pte_t *pte, int nr)
+{
+       if (IS_ALIGNED(sizeof(*pte), KASAN_GRANULE_SIZE))
+               kasan_poison(pte, sizeof(*pte) * nr, KASAN_LAZY_MMU_PTE, false);
+}
+EXPORT_SYMBOL_GPL(__kasan_poison_pte);
+
+void __kasan_unpoison_pte(pte_t *pte, int nr)
+{
+       if (IS_ALIGNED(sizeof(*pte), KASAN_GRANULE_SIZE))
+               kasan_unpoison(pte, sizeof(*pte) * nr, false);
+}
+EXPORT_SYMBOL_GPL(__kasan_unpoison_pte);
+
 void __kasan_unpoison_new_object(struct kmem_cache *cache, void *object)
 {
        kasan_unpoison(object, cache->object_size, false);

mm/kasan/kasan.h +2 -0

index fc9169a54766..1a2d18cdb21d 100644
@@ -144,12 +144,14 @@ static inline bool kasan_requires_meta(void)
 #define KASAN_PAGE_REDZONE     0xFE  /* redzone for kmalloc_large allocation */
 #define KASAN_SLAB_REDZONE     0xFC  /* redzone for slab object */
 #define KASAN_SLAB_FREE                0xFB  /* freed slab object */
+#define KASAN_LAZY_MMU_PTE     0xFD  /* direct pte access in lazy mmu mode */
 #define KASAN_VMALLOC_INVALID  0xF8  /* inaccessible space in vmap area */
 #else
 #define KASAN_PAGE_FREE                KASAN_TAG_INVALID
 #define KASAN_PAGE_REDZONE     KASAN_TAG_INVALID
 #define KASAN_SLAB_REDZONE     KASAN_TAG_INVALID
 #define KASAN_SLAB_FREE                KASAN_TAG_INVALID
+#define KASAN_LAZY_MMU_PTE     KASAN_TAG_INVALID
 #define KASAN_VMALLOC_INVALID  KASAN_TAG_INVALID /* only used for SW_TAGS */
 #endif
 

mm/kasan/report_generic.c +3 -1

index f5b8e37b3805..489d4a8d6902 100644
@@ -113,6 +113,9 @@ static const char *get_shadow_bug_type(struct kasan_report_info *info)
        case KASAN_SLAB_FREE_META:
                bug_type = "slab-use-after-free";
                break;
+       case KASAN_LAZY_MMU_PTE:
+               bug_type = "lazy-mmu-pte-access";
+               break;
        case KASAN_ALLOCA_LEFT:
        case KASAN_ALLOCA_RIGHT:
                bug_type = "alloca-out-of-bounds";
--

2.53.0

--
You received this message because you are subscribed to the Google Groups "kasan-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/kasan-dev/52c9be0cf71a8896a5d76c148c38fb24a2005dd9.1786956464.git.agordeev%40linux.ibm.com.

Hi Alexander,

Should all this be limited to only s390?

Thanks!

On Tue, Aug 18, 2026 at 12:11:34AM +0200, Andrey Konovalov wrote:
...

Quoted 3 lines

Hi Alexander,

Should all this be limited to only s390?

The idea is to allow any architecture to opt-in. Once [1] is accepted this may look redundant, but I still see the benefit in having it.

Quoted 8 lines · Alexander Gordeev

On Tue, Aug 18, 2026 at 12:11:34AM +0200, Andrey Konovalov wrote:
...

Quoted 3 lines

Hi Alexander,

Should all this be limited to only s390?

The idea is to allow any architecture to opt-in. Once [1] is accepted this may look redundant, but I still see the benefit in having it.

What would be the benefit if [1] is accepted?

Quoted 7 lines · Heiko Carstens

Quoted 6 lines · Alexander Gordeev

On Tue, Aug 18, 2026 at 12:11:34AM +0200, Andrey Konovalov wrote:
...

Quoted 3 lines

Hi Alexander,

Should all this be limited to only s390?

Quoted 4 lines

Quoted 2 lines

The idea is to allow any architecture to opt-in. Once [1] is accepted this may look redundant, but I still see the benefit in having it.

What would be the benefit if [1] is accepted?

Just another mechanism for verification, and pretty cheap one. I would dare to say [1] does not rule out an invalid access completely.