qemu-commits
[Top][All Lists]
Advanced

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

[Qemu-commits] [qemu/qemu] 3830df: configure: Loosen GCC requirement fro


From: Richard Henderson
Subject: [Qemu-commits] [qemu/qemu] 3830df: configure: Loosen GCC requirement from 7.5.0 to 7.4.0
Date: Sun, 03 Oct 2021 08:12:28 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 3830df5f83b9b52d9496763ce1a50afb9231c998
      
https://github.com/qemu/qemu/commit/3830df5f83b9b52d9496763ce1a50afb9231c998
  Author: nia <nia@NetBSD.org>
  Date:   2021-10-02 (Sat, 02 Oct 2021)

  Changed paths:
    M configure

  Log Message:
  -----------
  configure: Loosen GCC requirement from 7.5.0 to 7.4.0

As discussed in issue 614, we're shipping GCC 7.4.0 as the
system compiler in NetBSD 9, the most recent stable branch,
and are still actively interested in QEMU on this platform.

The differences between GCC 7.5.0 and 7.4.0 are trivial.

Signed-off-by: Nia Alarie <nia@NetBSD.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <YVcpe79I0rly1HJh@homeworld.netbsd.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 75b98cb9f6456ccf194211beffcbf93b0a995fa4
      
https://github.com/qemu/qemu/commit/75b98cb9f6456ccf194211beffcbf93b0a995fa4
  Author: David Hildenbrand <david@redhat.com>
  Date:   2021-10-02 (Sat, 02 Oct 2021)

  Changed paths:
    M hw/virtio/virtio-mem-pci.c

  Log Message:
  -----------
  virtio-mem-pci: Fix memory leak when creating MEMORY_DEVICE_SIZE_CHANGE event

Apparently, we don't have to duplicate the string.

Fixes: 722a3c783ef4 ("virtio-pci: Send qapi events when the virtio-mem size 
changes")
Cc: qemu-stable@nongnu.org
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20210929162445.64060-2-david@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: d89dd28f0e29c9eae997b0cd645208454a2f3374
      
https://github.com/qemu/qemu/commit/d89dd28f0e29c9eae997b0cd645208454a2f3374
  Author: David Hildenbrand <david@redhat.com>
  Date:   2021-10-02 (Sat, 02 Oct 2021)

  Changed paths:
    M hw/virtio/virtio-mem-pci.c
    M qapi/machine.json

  Log Message:
  -----------
  qapi: Include qom-path in MEMORY_DEVICE_SIZE_CHANGE qapi events

As we might not always have a device id, it is impossible to always
match MEMORY_DEVICE_SIZE_CHANGE events to an actual device. Let's
include the qom-path in the event, which allows for reliable mapping of
events to devices.

Fixes: 722a3c783ef4 ("virtio-pci: Send qapi events when the virtio-mem size 
changes")
Suggested-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20210929162445.64060-3-david@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 77ae2302ae167aa840d5a3aa489f7958db7c1426
      
https://github.com/qemu/qemu/commit/77ae2302ae167aa840d5a3aa489f7958db7c1426
  Author: David Hildenbrand <david@redhat.com>
  Date:   2021-10-02 (Sat, 02 Oct 2021)

  Changed paths:
    M monitor/monitor.c

  Log Message:
  -----------
  monitor: Rate-limit MEMORY_DEVICE_SIZE_CHANGE qapi events per device

We want to rate-limit MEMORY_DEVICE_SIZE_CHANGE events per device,
otherwise we can lose some events for devices. We can now use the
qom-path to reliably map an event to a device and make rate-limiting
device-aware.

This was noticed by starting a VM with two virtio-mem devices that each
have a requested size > 0. The Linux guest will initialize both devices
in parallel, resulting in losing MEMORY_DEVICE_SIZE_CHANGE events for
one of the devices.

Fixes: 722a3c783ef4 ("virtio-pci: Send qapi events when the virtio-mem size 
changes")
Suggested-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20210929162445.64060-4-david@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 45e576c74533c70b38ba00f0c298dcdbc1635163
      
https://github.com/qemu/qemu/commit/45e576c74533c70b38ba00f0c298dcdbc1635163
  Author: David Hildenbrand <david@redhat.com>
  Date:   2021-10-02 (Sat, 02 Oct 2021)

  Changed paths:
    M hw/tpm/tpm_ppi.c

  Log Message:
  -----------
  tpm: mark correct memory region range dirty when clearing RAM

We might not start at the beginning of the memory region. Let's
calculate the offset into the memory region via the difference in the
host addresses.

Acked-by: Stefan Berger <stefanb@linux.ibm.com>
Fixes: ffab1be70692 ("tpm: clear RAM when "memory overwrite" requested")
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Claudio Fontana <cfontana@suse.de>
Cc: Thomas Huth <thuth@redhat.com>
Cc: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20210727082545.17934-2-david@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 602f8ea79ce39b7bd6d2e22c686ef05227e1876b
      
https://github.com/qemu/qemu/commit/602f8ea79ce39b7bd6d2e22c686ef05227e1876b
  Author: David Hildenbrand <david@redhat.com>
  Date:   2021-10-02 (Sat, 02 Oct 2021)

  Changed paths:
    M softmmu/memory_mapping.c

  Log Message:
  -----------
  softmmu/memory_mapping: never merge ranges accross memory regions

Let's make sure to not merge when different memory regions are involved.
Unlikely, but theoretically possible.

Acked-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Claudio Fontana <cfontana@suse.de>
Cc: Thomas Huth <thuth@redhat.com>
Cc: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20210727082545.17934-3-david@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 3513bb1be1f025e011a69bafd02b6f59fa1d8383
      
https://github.com/qemu/qemu/commit/3513bb1be1f025e011a69bafd02b6f59fa1d8383
  Author: David Hildenbrand <david@redhat.com>
  Date:   2021-10-02 (Sat, 02 Oct 2021)

  Changed paths:
    M softmmu/memory_mapping.c

  Log Message:
  -----------
  softmmu/memory_mapping: factor out adding physical memory ranges

Let's factor out adding a MemoryRegionSection to the list, to be reused in
RamDiscardManager context next.

Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Claudio Fontana <cfontana@suse.de>
Cc: Thomas Huth <thuth@redhat.com>
Cc: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20210727082545.17934-4-david@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: cb83ba8c1ab856b4327e7e869c410bbfd4152c2c
      
https://github.com/qemu/qemu/commit/cb83ba8c1ab856b4327e7e869c410bbfd4152c2c
  Author: David Hildenbrand <david@redhat.com>
  Date:   2021-10-02 (Sat, 02 Oct 2021)

  Changed paths:
    M softmmu/memory_mapping.c

  Log Message:
  -----------
  softmmu/memory_mapping: optimize for RamDiscardManager sections

virtio-mem logically plugs/unplugs memory within a sparse memory region
and notifies via the RamDiscardManager interface when parts become
plugged (populated) or unplugged (discarded).

Currently, we end up (via the two users)
1) zeroing all logically unplugged/discarded memory during TPM resets.
2) reading all logically unplugged/discarded memory when dumping, to
   figure out the content is zero.

1) is always bad, because we assume unplugged memory stays discarded
   (and is already implicitly zero).
2) isn't that bad with anonymous memory, we end up reading the zero
   page (slow and unnecessary, though). However, once we use some
   file-backed memory (future use case), even reading will populate memory.

Let's cut out all parts marked as not-populated (discarded) via the
RamDiscardManager. As virtio-mem is the single user, this now means that
logically unplugged memory ranges will no longer be included in the
dump, which results in smaller dump files and faster dumping.

virtio-mem has a minimum granularity of 1 MiB (and the default is usually
2 MiB). Theoretically, we can see quite some fragmentation, in practice
we won't have it completely fragmented in 1 MiB pieces. Still, we might
end up with many physical ranges.

Both, the ELF format and kdump seem to be ready to support many
individual ranges (e.g., for ELF it seems to be UINT32_MAX, kdump has a
linear bitmap).

Reviewed-by: Peter Xu <peterx@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Claudio Fontana <cfontana@suse.de>
Cc: Thomas Huth <thuth@redhat.com>
Cc: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20210727082545.17934-5-david@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 30bd1db58b09c12b68c35f041f919014b885482d
      
https://github.com/qemu/qemu/commit/30bd1db58b09c12b68c35f041f919014b885482d
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2021-10-03 (Sun, 03 Oct 2021)

  Changed paths:
    M configure
    M hw/tpm/tpm_ppi.c
    M hw/virtio/virtio-mem-pci.c
    M monitor/monitor.c
    M qapi/machine.json
    M softmmu/memory_mapping.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging

* -smp cleanpus (Yanan)
* Hyper-V enlightenment functionality (Vitaly)
* virtio-mem support in dump, tpm and QMP (David)
* NetBSD GCC 7.4 compiler support (Nia)

# gpg: Signature made Sun 03 Oct 2021 03:41:30 AM EDT
# gpg:                using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg:                issuer "pbonzini@redhat.com"
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full]
# gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>" [full]

* remotes/bonzini/tags/for-upstream:
  softmmu/memory_mapping: optimize for RamDiscardManager sections
  softmmu/memory_mapping: factor out adding physical memory ranges
  softmmu/memory_mapping: never merge ranges accross memory regions
  tpm: mark correct memory region range dirty when clearing RAM
  monitor: Rate-limit MEMORY_DEVICE_SIZE_CHANGE qapi events per device
  qapi: Include qom-path in MEMORY_DEVICE_SIZE_CHANGE qapi events
  virtio-mem-pci: Fix memory leak when creating MEMORY_DEVICE_SIZE_CHANGE event
  configure: Loosen GCC requirement from 7.5.0 to 7.4.0

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>


Compare: https://github.com/qemu/qemu/compare/f50ecf548c73...30bd1db58b09



reply via email to

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