| 4ca00a91 | 28-Aug-2026 |
Claudio Imbrenda <imbrenda@linux.ibm.com> |
KVM: s390: Fix race in _destroy_pages_crste()
Use READ_ONCE() in _destroy_pages_crste() to read the crste, avoid dereferencing the pointer multiple times.
Fixes: a2c17f9270cc ("KVM: s390: New gmap
KVM: s390: Fix race in _destroy_pages_crste()
Use READ_ONCE() in _destroy_pages_crste() to read the crste, avoid dereferencing the pointer multiple times.
Fixes: a2c17f9270cc ("KVM: s390: New gmap code") Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260828115439.145885-9-imbrenda@linux.ibm.com>
show more ...
|
| 27554b95 | 28-Aug-2026 |
Claudio Imbrenda <imbrenda@linux.ibm.com> |
KVM: s390: Fix potential races in dat skey functions
When dat_cond_set_storage_key() finds a large page, it will conditionally set the storage key in absolute memory using large_crste_to_phys() to g
KVM: s390: Fix potential races in dat skey functions
When dat_cond_set_storage_key() finds a large page, it will conditionally set the storage key in absolute memory using large_crste_to_phys() to get the absolute address.
There is a race window between dat_entry_walk() and large_crste_to_phys(): the large page could have been split concurrently, and large_crste_to_phys() might be called with a crste that does not designate a large page, leading to crashes.
Similar issues were also present in dat_set_storage_key().
dat_get_storage_key() and dat_reset_reference_bit() did instead check for a potential concurrent splitting of the large page, but then handled it incorrectly.
Fix by performing a READ_ONCE on the crste pointer, checking and using the result, instead of dereferencing the pointer again. In case a race is detacted, try dat_entry_walk() again.
Fixes: 8e03e8316eb2 ("KVM: s390: KVM page table management functions: storage keys") Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260828115439.145885-8-imbrenda@linux.ibm.com>
show more ...
|
| 19192a40 | 28-Aug-2026 |
Claudio Imbrenda <imbrenda@linux.ibm.com> |
KVM: s390: Move all code into s390_kvm_mmu_prepare_memory_region()
Move all code from s390_kvm_mmu_commit_memory_region() into s390_kvm_mmu_prepare_memory_region(). This allows the function to fail
KVM: s390: Move all code into s390_kvm_mmu_prepare_memory_region()
Move all code from s390_kvm_mmu_commit_memory_region() into s390_kvm_mmu_prepare_memory_region(). This allows the function to fail gracefully if needed. The previous behaviour was to print a warning and continue execution with page tables inconsistent with the memslots.
Fixes: e38c884df921 ("KVM: s390: Switch to new gmap") Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260828115439.145885-6-imbrenda@linux.ibm.com>
show more ...
|
| 188a15cc | 02-Jul-2026 |
Steffen Eiden <seiden@linux.ibm.com> |
KVM: s390: gmap: Make prefix handling optional
Guard guest prefix handling behind `KVM_S390_MANAGES_S390_GUEST`. This enables other KVM implementations to use gmap without implementing prefix handli
KVM: s390: gmap: Make prefix handling optional
Guard guest prefix handling behind `KVM_S390_MANAGES_S390_GUEST`. This enables other KVM implementations to use gmap without implementing prefix handling. The prefix handling is integrated deeply in the gmap implementation. Therefore, provide safe default implementations for the guarded functions.
No functional changes.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
show more ...
|
| ce4bee6a | 03-Aug-2026 |
Steffen Eiden <seiden@linux.ibm.com> |
KVM: s390: gmap: Make CMMA optional
Guard guest CMMA behind `KVM_S390_MANAGES_S390_GUEST`. This enables other KVM implementations to use gmap without implementing CMMA.
No functional changes.
Sign
KVM: s390: gmap: Make CMMA optional
Guard guest CMMA behind `KVM_S390_MANAGES_S390_GUEST`. This enables other KVM implementations to use gmap without implementing CMMA.
No functional changes.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
show more ...
|
| a07276d5 | 03-Aug-2026 |
Steffen Eiden <seiden@linux.ibm.com> |
KVM: s390: gmap: Make storage keys optional
Guard guest storage key handling behind `KVM_S390_MANAGES_S390_GUEST`. This enables other KVM implementations to use gmap without implementing storage key
KVM: s390: gmap: Make storage keys optional
Guard guest storage key handling behind `KVM_S390_MANAGES_S390_GUEST`. This enables other KVM implementations to use gmap without implementing storage key infrastructure. Define KVM_S390_MANAGES_S390_GUEST to 1 for KVM hosts managing s390 guests (in kvm_host_s390.h). A KVM implementation not implementing those features must define KVM_S390_MANAGES_S390_GUEST to 0 in its kvm_host_<guest_arch>.h.
No functional changes besides the new guard.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
show more ...
|