qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] ecd666: MAINTAINERS: Update S390 PCI Maintain


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] ecd666: MAINTAINERS: Update S390 PCI Maintainer
Date: Mon, 30 Sep 2019 08:56:25 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: ecd6663d95c94e1f1b736eab4254c2debd94edc1
      
https://github.com/qemu/qemu/commit/ecd6663d95c94e1f1b736eab4254c2debd94edc1
  Author: Matthew Rosato <address@hidden>
  Date:   2019-09-30 (Mon, 30 Sep 2019)

  Changed paths:
    M MAINTAINERS

  Log Message:
  -----------
  MAINTAINERS: Update S390 PCI Maintainer

As discussed previously with Collin, I will take over maintaining
s390 pci.

Signed-off-by: Matthew Rosato <address@hidden>
Message-Id: <address@hidden>
Acked-by: Collin Walling <address@hidden>
Signed-off-by: Christian Borntraeger <address@hidden>


  Commit: 7df1dac5f1c85312474df9cb3a8fcae72303da62
      
https://github.com/qemu/qemu/commit/7df1dac5f1c85312474df9cb3a8fcae72303da62
  Author: Matthew Rosato <address@hidden>
  Date:   2019-09-30 (Mon, 30 Sep 2019)

  Changed paths:
    M hw/s390x/s390-pci-bus.c

  Log Message:
  -----------
  s390: PCI: fix IOMMU region init

The fix in dbe9cf606c shrinks the IOMMU memory region to a size
that seems reasonable on the surface, however is actually too
small as it is based against a 0-mapped address space.  This
causes breakage with small guests as they can overrun the IOMMU window.

Let's go back to the prior method of initializing iommu for now.

Fixes: dbe9cf606c ("s390x/pci: Set the iommu region size mpcifc request")
Cc: address@hidden
Reviewed-by: Pierre Morel <address@hidden>
Reported-by: Boris Fiuczynski <address@hidden>
Tested-by: Boris Fiuczynski <address@hidden>
Reported-by: Stefan Zimmerman <address@hidden>
Signed-off-by: Matthew Rosato <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Christian Borntraeger <address@hidden>


  Commit: 679b844756e4eaa1b94bb82f52ec9f999dc4f851
      
https://github.com/qemu/qemu/commit/679b844756e4eaa1b94bb82f52ec9f999dc4f851
  Author: Janosch Frank <address@hidden>
  Date:   2019-09-30 (Mon, 30 Sep 2019)

  Changed paths:
    M hw/s390x/event-facility.c
    M hw/s390x/sclp.c

  Log Message:
  -----------
  s390x: sclp: refactor invalid command check

Invalid command checking has to be done before the boundary check,
refactoring it now allows to insert the boundary check at the correct
place later.

Signed-off-by: Janosch Frank <address@hidden>
Reviewed-by: Jason J. Herne <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
Signed-off-by: Christian Borntraeger <address@hidden>


  Commit: 6f6c9333efaf43d5a6f435266444aa2c51ac11b2
      
https://github.com/qemu/qemu/commit/6f6c9333efaf43d5a6f435266444aa2c51ac11b2
  Author: Janosch Frank <address@hidden>
  Date:   2019-09-30 (Mon, 30 Sep 2019)

  Changed paths:
    M hw/s390x/sclp.c

  Log Message:
  -----------
  s390x: sclp: boundary check

All sclp codes need to be checked for page boundary violations.

Signed-off-by: Janosch Frank <address@hidden>
Reviewed-by: Jason J. Herne <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
Signed-off-by: Christian Borntraeger <address@hidden>


  Commit: d959f6cf502f37ddda91140a2e7a2e2b72de397e
      
https://github.com/qemu/qemu/commit/d959f6cf502f37ddda91140a2e7a2e2b72de397e
  Author: Janosch Frank <address@hidden>
  Date:   2019-09-30 (Mon, 30 Sep 2019)

  Changed paths:
    M hw/s390x/sclp.c

  Log Message:
  -----------
  s390x: sclp: fix error handling for oversize control blocks

Requests over 4k are not a spec exception.

Signed-off-by: Janosch Frank <address@hidden>
Reviewed-by: Jason J. Herne <address@hidden>
Message-Id: <address@hidden>
Acked-by: David Hildenbrand <address@hidden>
Signed-off-by: Christian Borntraeger <address@hidden>


  Commit: 832be0d8a3bb7b54d64730f7a37d674f30ca0427
      
https://github.com/qemu/qemu/commit/832be0d8a3bb7b54d64730f7a37d674f30ca0427
  Author: Claudio Imbrenda <address@hidden>
  Date:   2019-09-30 (Mon, 30 Sep 2019)

  Changed paths:
    M hw/s390x/sclp.c

  Log Message:
  -----------
  s390x: sclp: Report insufficient SCCB length

Return the correct error code when the SCCB buffer is too small to
contain all of the output, for the Read SCP Information and
Read CPU Information commands.

Signed-off-by: Claudio Imbrenda <address@hidden>
Reviewed-by: Jason J. Herne <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
Signed-off-by: Christian Borntraeger <address@hidden>


  Commit: ee35e9684c334523e2864b1f9c31f0838e834343
      
https://github.com/qemu/qemu/commit/ee35e9684c334523e2864b1f9c31f0838e834343
  Author: Thomas Huth <address@hidden>
  Date:   2019-09-30 (Mon, 30 Sep 2019)

  Changed paths:
    M configure

  Log Message:
  -----------
  configure: Remove s390 (31-bit mode) from the list of supported CPUs

On IBM Z, KVM in the kernel is only implemented for 64-bit mode, and
with regards to TCG, we also only support 64-bit host CPUs (see the
check at the beginning of tcg/s390/tcg-target.inc.c), so we should
remove s390 (without "x", i.e. the old 31-bit mode CPUs) from the
list of supported CPUs.

Signed-off-by: Thomas Huth <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
Signed-off-by: Christian Borntraeger <address@hidden>


  Commit: 4222147dfb7229de36d8cc8c9fa3543b43347241
      
https://github.com/qemu/qemu/commit/4222147dfb7229de36d8cc8c9fa3543b43347241
  Author: Paolo Bonzini <address@hidden>
  Date:   2019-09-30 (Mon, 30 Sep 2019)

  Changed paths:
    M accel/kvm/kvm-all.c

  Log Message:
  -----------
  kvm: extract kvm_log_clear_one_slot

We may need to clear the dirty bitmap for more than one KVM memslot.
First do some code movement with no semantic change.

Signed-off-by: Paolo Bonzini <address@hidden>
Signed-off-by: Igor Mammedov <address@hidden>
Reviewed-by: Peter Xu <address@hidden>
Message-Id: <address@hidden>
Acked-by: Paolo Bonzini <address@hidden>
Signed-off-by: Christian Borntraeger <address@hidden>
[fixup line break]


  Commit: 84516e5b8db66b8a169a8fdd4c25568ed0b67a3a
      
https://github.com/qemu/qemu/commit/84516e5b8db66b8a169a8fdd4c25568ed0b67a3a
  Author: Paolo Bonzini <address@hidden>
  Date:   2019-09-30 (Mon, 30 Sep 2019)

  Changed paths:
    M accel/kvm/kvm-all.c

  Log Message:
  -----------
  kvm: clear dirty bitmaps from all overlapping memslots

Currently MemoryRegionSection has 1:1 mapping to KVMSlot.
However next patch will allow splitting MemoryRegionSection into
several KVMSlot-s, make sure that kvm_physical_log_slot_clear()
is able to handle such 1:N mapping.

Signed-off-by: Paolo Bonzini <address@hidden>
Signed-off-by: Igor Mammedov <address@hidden>
Reviewed-by: Peter Xu <address@hidden>
Message-Id: <address@hidden>
Acked-by: Paolo Bonzini <address@hidden>
Signed-off-by: Christian Borntraeger <address@hidden>


  Commit: 023ae9a88a7cfbdf6f23c3b78ccfcb9b1e26da98
      
https://github.com/qemu/qemu/commit/023ae9a88a7cfbdf6f23c3b78ccfcb9b1e26da98
  Author: Igor Mammedov <address@hidden>
  Date:   2019-09-30 (Mon, 30 Sep 2019)

  Changed paths:
    M accel/kvm/kvm-all.c
    M include/sysemu/kvm_int.h

  Log Message:
  -----------
  kvm: split too big memory section on several memslots

Max memslot size supported by kvm on s390 is 8Tb,
move logic of splitting RAM in chunks upto 8T to KVM code.

This way it will hide KVM specific restrictions in KVM code
and won't affect board level design decisions. Which would allow
us to avoid misusing memory_region_allocate_system_memory() API
and eventually use a single hostmem backend for guest RAM.

Signed-off-by: Igor Mammedov <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Peter Xu <address@hidden>
Acked-by: Paolo Bonzini <address@hidden>
Signed-off-by: Christian Borntraeger <address@hidden>


  Commit: fb1fc5a82b836fe1e0d6f5dd57164a82e674ea8a
      
https://github.com/qemu/qemu/commit/fb1fc5a82b836fe1e0d6f5dd57164a82e674ea8a
  Author: Igor Mammedov <address@hidden>
  Date:   2019-09-30 (Mon, 30 Sep 2019)

  Changed paths:
    M hw/s390x/s390-virtio-ccw.c
    M target/s390x/kvm.c

  Log Message:
  -----------
  s390: do not call memory_region_allocate_system_memory() multiple times

s390 was trying to solve limited KVM memslot size issue by abusing
memory_region_allocate_system_memory(), which breaks API contract
where the function might be called only once.

Beside an invalid use of API, the approach also introduced migration
issue, since RAM chunks for each KVM_SLOT_MAX_BYTES are transferred in
migration stream as separate RAMBlocks.

After discussion [1], it was agreed to break migration from older
QEMU for guest with RAM >8Tb (as it was relatively new (since 2.12)
and considered to be not actually used downstream).
Migration should keep working for guests with less than 8TB and for
more than 8TB with QEMU 4.2 and newer binary.
In case user tries to migrate more than 8TB guest, between incompatible
QEMU versions, migration should fail gracefully due to non-exiting
RAMBlock ID or RAMBlock size mismatch.

Taking in account above and that now KVM code is able to split too
big MemorySection into several memslots, partially revert commit
 (bb223055b s390-ccw-virtio: allow for systems larger that 7.999TB)
and use kvm_set_max_memslot_size() to set KVMSlot size to
KVM_SLOT_MAX_BYTES.

1) [PATCH RFC v2 4/4] s390: do not call  memory_region_allocate_system_memory() 
multiple times

Signed-off-by: Igor Mammedov <address@hidden>
Message-Id: <address@hidden>
Acked-by: Peter Xu <address@hidden>
Signed-off-by: Christian Borntraeger <address@hidden>


  Commit: c5b9ce518c0551d0198bcddadc82e03de9ac8de9
      
https://github.com/qemu/qemu/commit/c5b9ce518c0551d0198bcddadc82e03de9ac8de9
  Author: Christian Borntraeger <address@hidden>
  Date:   2019-09-30 (Mon, 30 Sep 2019)

  Changed paths:
    M target/s390x/kvm.c

  Log Message:
  -----------
  s390/kvm: split kvm mem slots at 4TB

Instead of splitting at an unaligned address, we can simply split at
4TB.

Signed-off-by: Christian Borntraeger <address@hidden>
Acked-by: Igor Mammedov <address@hidden>


  Commit: 95e9d74fe4281f7ad79a5a7511400541729aa44a
      
https://github.com/qemu/qemu/commit/95e9d74fe4281f7ad79a5a7511400541729aa44a
  Author: Peter Maydell <address@hidden>
  Date:   2019-09-30 (Mon, 30 Sep 2019)

  Changed paths:
    M MAINTAINERS
    M accel/kvm/kvm-all.c
    M configure
    M hw/s390x/event-facility.c
    M hw/s390x/s390-pci-bus.c
    M hw/s390x/s390-virtio-ccw.c
    M hw/s390x/sclp.c
    M include/sysemu/kvm_int.h
    M target/s390x/kvm.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/borntraeger/tags/s390x-20190930' into 
staging

- do not abuse memory_region_allocate_system_memory and split the memory
  according to KVM memslots in KVM code instead (Paolo, Igor)
- change splitting to split at 4TB (Christian)
- do not claim s390 (31bit) support in configure (Thomas)
- sclp error checking (Janosch, Claudio)
- new s390 pci maintainer (Matt, Collin)
- fix s390 pci (again) (Matt)

# gpg: Signature made Mon 30 Sep 2019 12:52:51 BST
# gpg:                using RSA key 117BBC80B5A61C7C
# gpg: Good signature from "Christian Borntraeger (IBM) <address@hidden>" [full]
# Primary key fingerprint: F922 9381 A334 08F9 DBAB  FBCA 117B BC80 B5A6 1C7C

* remotes/borntraeger/tags/s390x-20190930:
  s390/kvm: split kvm mem slots at 4TB
  s390: do not call memory_region_allocate_system_memory() multiple times
  kvm: split too big memory section on several memslots
  kvm: clear dirty bitmaps from all overlapping memslots
  kvm: extract kvm_log_clear_one_slot
  configure: Remove s390 (31-bit mode) from the list of supported CPUs
  s390x: sclp: Report insufficient SCCB length
  s390x: sclp: fix error handling for oversize control blocks
  s390x: sclp: boundary check
  s390x: sclp: refactor invalid command check
  s390: PCI: fix IOMMU region init
  MAINTAINERS: Update S390 PCI Maintainer

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/786d36ad416c...95e9d74fe428



reply via email to

[Prev in Thread] Current Thread [Next in Thread]