Hi Linus,

please pull s390 updates for 5.18-rc6. Please note that this pull
request includes two s390 specific kvm commits, which normally would
have been routed via the kvm tree.

Due to lack of other patches in the kvm tree Christian Borntraeger
asked to get them upstream via the s390 tree:
https://lore.kernel.org/linux-s390/249d0100-fa58-bf48-b1d2-f28e94c3a5f2@linux.ibm.com/

Thanks,
Heiko

The following changes since commit af2d861d4cd2a4da5137f795ee3509e6f944a25b:

  Linux 5.18-rc4 (2022-04-24 14:51:22 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-5.18-4

for you to fetch changes up to a06afe8383080c630a7a528b8382fc6bb4925b61:

  KVM: s390: vsie/gmap: reduce gmap_rmap overhead (2022-05-03 15:15:44 +0200)

----------------------------------------------------------------
s390 updates for 5.18-rc6

- Disable -Warray-bounds warning for gcc12, since there known way to
  workaround false positive warnings on lowcore accesses would result
  in worse code on fast paths.

- Avoid lockdep_assert_held() warning in kvm vm memop code.

- Reduce overhead within gmap_rmap code to get rid of long latencies
  when e.g. shutting down 2nd level guests.

----------------------------------------------------------------
Christian Borntraeger (1):
      KVM: s390: vsie/gmap: reduce gmap_rmap overhead

Janis Schoetterl-Glausch (1):
      KVM: s390: Fix lockdep issue in vm memop

Sven Schnelle (1):
      s390: disable -Warray-bounds

 arch/s390/Makefile       | 10 ++++++++++
 arch/s390/kvm/kvm-s390.c | 11 ++++++++++-
 arch/s390/mm/gmap.c      |  7 +++++++
 3 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/s390/Makefile b/arch/s390/Makefile
index e441b60b1812..df325eacf62d 100644
--- a/arch/s390/Makefile
+++ b/arch/s390/Makefile
@@ -30,6 +30,16 @@ KBUILD_CFLAGS_DECOMPRESSOR += -fno-stack-protector
 KBUILD_CFLAGS_DECOMPRESSOR += $(call cc-disable-warning, address-of-packed-member)
 KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO),-g)
 KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO_DWARF4), $(call cc-option, -gdwarf-4,))
+
+ifdef CONFIG_CC_IS_GCC
+	ifeq ($(call cc-ifversion, -ge, 1200, y), y)
+		ifeq ($(call cc-ifversion, -lt, 1300, y), y)
+			KBUILD_CFLAGS += $(call cc-disable-warning, array-bounds)
+			KBUILD_CFLAGS_DECOMPRESSOR += $(call cc-disable-warning, array-bounds)
+		endif
+	endif
+endif
+
 UTS_MACHINE	:= s390x
 STACK_SIZE	:= $(if $(CONFIG_KASAN),65536,16384)
 CHECKFLAGS	+= -D__s390__ -D__s390x__
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index da3dabda1a12..76ad6408cb2c 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -2384,7 +2384,16 @@ static int kvm_s390_vm_mem_op(struct kvm *kvm, struct kvm_s390_mem_op *mop)
 		return -EINVAL;
 	if (mop->size > MEM_OP_MAX_SIZE)
 		return -E2BIG;
-	if (kvm_s390_pv_is_protected(kvm))
+	/*
+	 * This is technically a heuristic only, if the kvm->lock is not
+	 * taken, it is not guaranteed that the vm is/remains non-protected.
+	 * This is ok from a kernel perspective, wrongdoing is detected
+	 * on the access, -EFAULT is returned and the vm may crash the
+	 * next time it accesses the memory in question.
+	 * There is no sane usecase to do switching and a memop on two
+	 * different CPUs at the same time.
+	 */
+	if (kvm_s390_pv_get_handle(kvm))
 		return -EINVAL;
 	if (mop->flags & KVM_S390_MEMOP_F_SKEY_PROTECTION) {
 		if (access_key_invalid(mop->key))
diff --git a/arch/s390/mm/gmap.c b/arch/s390/mm/gmap.c
index af03cacf34ec..1ac73917a8d3 100644
--- a/arch/s390/mm/gmap.c
+++ b/arch/s390/mm/gmap.c
@@ -1183,6 +1183,7 @@ EXPORT_SYMBOL_GPL(gmap_read_table);
 static inline void gmap_insert_rmap(struct gmap *sg, unsigned long vmaddr,
 				    struct gmap_rmap *rmap)
 {
+	struct gmap_rmap *temp;
 	void __rcu **slot;
 
 	BUG_ON(!gmap_is_shadow(sg));
@@ -1190,6 +1191,12 @@ static inline void gmap_insert_rmap(struct gmap *sg, unsigned long vmaddr,
 	if (slot) {
 		rmap->next = radix_tree_deref_slot_protected(slot,
 							&sg->guest_table_lock);
+		for (temp = rmap->next; temp; temp = temp->next) {
+			if (temp->raddr == rmap->raddr) {
+				kfree(rmap);
+				return;
+			}
+		}
 		radix_tree_replace_slot(&sg->host_to_rmap, slot, rmap);
 	} else {
 		rmap->next = NULL;

The pull request you sent on Thu, 5 May 2022 14:39:42 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-5.18-4

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0f5d752b1395e777ef81e28886945e5e939b7c8a

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

On 5/5/22 14:39, Heiko Carstens wrote:
> Hi Linus,
> 
> please pull s390 updates for 5.18-rc6. Please note that this pull
> request includes two s390 specific kvm commits, which normally would
> have been routed via the kvm tree.
> 
> Due to lack of other patches in the kvm tree Christian Borntraeger
> asked to get them upstream via the s390 tree:
> https://lore.kernel.org/linux-s390/249d0100-fa58-bf48-b1d2-f28e94c3a5f2@linux.ibm.com/

Needless to say, kvm patches have since materialized and I'll send a 
pull request later this week.

But anyway s390 is the architecture where I expect zero issues if KVM 
patches go in through arch maintainers.  Compared to other 
architectures, there are a lot more points of contact between KVM and 
the rest of arch/s390; you know the KVM code well; and honestly the 
whole architecture is mostly Amharic to me when it comes to the 
privileged interface.

Thanks,

Paolo