[Qemu-commits] [qemu/qemu] 99d88d: memory-device: Unify enabled vs. supp

qemu-commits
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 99d88d: memory-device: Unify enabled vs. supp

From:	Richard Henderson
Subject:	[Qemu-commits] [qemu/qemu] 99d88d: memory-device: Unify enabled vs. supported error m...
Date:	Wed, 12 Jul 2023 03:08:13 -0700
  Branch: refs/heads/staging
  Home:   https://github.com/qemu/qemu
  Commit: 99d88de6eb577ff70cc1b1ed59f1a50f16038c2e
      
https://github.com/qemu/qemu/commit/99d88de6eb577ff70cc1b1ed59f1a50f16038c2e
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M hw/mem/memory-device.c

  Log Message:
  -----------
  memory-device: Unify enabled vs. supported error messages

Let's unify the error messages, such that we can simply stop allocating
ms->device_memory if the size would be 0 (and there are no memory
devices ever).

The case of "not supported by the machine" should barely pop up either
way: if the machine doesn't support memory devices, it usually doesn't
call the pre_plug handler ...

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20230623124553.400585-2-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: cc0afd8a72996352e9f3f11b1cdde49b08aa11b6
      
https://github.com/qemu/qemu/commit/cc0afd8a72996352e9f3f11b1cdde49b08aa11b6
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M hw/mem/memory-device.c
    M include/hw/boards.h

  Log Message:
  -----------
  memory-device: Introduce machine_memory_devices_init()

Let's intrduce a new helper that we will use to replace existing memory
device setup code during machine initialization. We'll enforce that the
size has to be > 0.

Once all machines were converted, we'll only allocate ms->device_memory
if the size > 0.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20230623124553.400585-3-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: 176d073029083dd52e28e92c5712d0535a83c34d
      
https://github.com/qemu/qemu/commit/176d073029083dd52e28e92c5712d0535a83c34d
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M hw/arm/virt.c

  Log Message:
  -----------
  hw/arm/virt: Use machine_memory_devices_init()

Let's use our new helper. We'll add the subregion to system RAM now
earlier. That shouldn't matter, because the system RAM memory region should
already be alive at that point.

Cc: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20230623124553.400585-4-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: c0ce7b4acb61c6a8376ff9e0d5cae2d58ac3bf1b
      
https://github.com/qemu/qemu/commit/c0ce7b4acb61c6a8376ff9e0d5cae2d58ac3bf1b
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_hcall.c

  Log Message:
  -----------
  hw/ppc/spapr: Use machine_memory_devices_init()

Let's use our new helper and stop always allocating ms->device_memory.
There is no difference in common memory-device code anymore between
ms->device_memory being NULL or the size being 0. So we only have to
teach spapr code that ms->device_memory isn't always around.

We can now modify two maxram_size checks to rely on ms->device_memory
for detecting whether we have memory devices.

Cc: Daniel Henrique Barboza <danielhb413@gmail.com>
Cc: "Cédric Le Goater" <clg@kaod.org>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Greg Kurz <groug@kaod.org>
Cc: Harsh Prateek Bora <harshpb@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20230623124553.400585-5-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: b13e115ff497581c60c94d4afca33225b1f69faf
      
https://github.com/qemu/qemu/commit/b13e115ff497581c60c94d4afca33225b1f69faf
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M hw/loongarch/virt.c

  Log Message:
  -----------
  hw/loongarch/virt: Use machine_memory_devices_init()

Let's use our new helper. While at it, use VIRT_HIGHMEM_BASE.

Cc: Xiaojuan Yang <yangxiaojuan@loongson.cn>
Cc: Song Gao <gaosong@loongson.cn>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20230623124553.400585-6-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: 78732a765986d5270d6b3d88afeb9e4d33092360
      
https://github.com/qemu/qemu/commit/78732a765986d5270d6b3d88afeb9e4d33092360
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M hw/i386/pc.c

  Log Message:
  -----------
  hw/i386/pc: Use machine_memory_devices_init()

Let's use our new helper and stop always allocating ms->device_memory.
Once allcoated, we're sure that the size > 0 and that the base was
initialized.

Adjust the code in pc_memory_init() to check for machine->device_memory
instead of pcmc->has_reserved_memory and machine->device_memory->base.

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Eduardo Habkost <eduardo@habkost.net>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20230623124553.400585-7-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: 75d5f34396c7f951f99a8c9800db29b4a98c8f67
      
https://github.com/qemu/qemu/commit/75d5f34396c7f951f99a8c9800db29b4a98c8f67
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M hw/i386/acpi-build.c

  Log Message:
  -----------
  hw/i386/acpi-build: Rely on machine->device_memory when building SRAT

We're already looking at machine->device_memory when calling
build_srat_memory(), so let's simply avoid going via
PC_MACHINE_DEVMEM_REGION_SIZE to get the size and rely on
machine->device_memory directly.

Once machine->device_memory is set, we know that the size > 0. The code now
looks much more similar the hw/arm/virt-acpi-build.c variant.

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Eduardo Habkost <eduardo@habkost.net>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20230623124553.400585-8-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: a8e67ce35b74e8bec70d39f86886439208c7b645
      
https://github.com/qemu/qemu/commit/a8e67ce35b74e8bec70d39f86886439208c7b645
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M hw/i386/pc.c
    M include/hw/i386/pc.h

  Log Message:
  -----------
  hw/i386/pc: Remove PC_MACHINE_DEVMEM_REGION_SIZE

There are no remaining users in the tree. Libvirt never used that
property and a quick internet search revealed no other users.

Further, we renamed that property already in commit f2ffbe2b7dd0
("pc: rename "hotplug memory" terminology to "device memory"") without
anybody complaining.

So let's just get rid of it.

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Eduardo Habkost <eduardo@habkost.net>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20230623124553.400585-9-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: d7f4891c85886efde88e0893ec19f89a9d14138e
      
https://github.com/qemu/qemu/commit/d7f4891c85886efde88e0893ec19f89a9d14138e
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M hw/mem/memory-device.c

  Log Message:
  -----------
  memory-device: Refactor memory_device_pre_plug()

Let's move memory_device_check_addable() and basic checks out of
memory_device_get_free_addr() directly into memory_device_pre_plug().

Separating basic checks from address assignment is cleaner and
prepares for further changes.

As all memory device users now use memory_devices_init(), and that
function enforces that the size is 0, we can drop the check for an empty
region.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20230623124553.400585-10-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: ac23dd2f293c59a5cd2fb385162277b4a6aef769
      
https://github.com/qemu/qemu/commit/ac23dd2f293c59a5cd2fb385162277b4a6aef769
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M hw/mem/memory-device.c
    M include/hw/boards.h

  Log Message:
  -----------
  memory-device: Track used region size in DeviceMemoryState

Let's avoid iterating over all devices and simply track it in the
DeviceMemoryState.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20230623124553.400585-11-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: 1d44ff586f8a8e113379430750b5a0a2a3f64cf9
      
https://github.com/qemu/qemu/commit/1d44ff586f8a8e113379430750b5a0a2a3f64cf9
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M softmmu/physmem.c

  Log Message:
  -----------
  softmmu/physmem: Warn with ram_block_discard_range() on MAP_PRIVATE file 
mapping

ram_block_discard_range() cannot possibly do the right thing in
MAP_PRIVATE file mappings in the general case.

To achieve the documented semantics, we also have to punch a hole into
the file, possibly messing with other MAP_PRIVATE/MAP_SHARED mappings
of such a file.

For example, using VM templating -- see commit b17fbbe55cba ("migration:
allow private destination ram with x-ignore-shared") -- in combination with
any mechanism that relies on discarding of RAM is problematic. This
includes:
* Postcopy live migration
* virtio-balloon inflation/deflation or free-page-reporting
* virtio-mem

So at least warn that there is something possibly dangerous is going on
when using ram_block_discard_range() in these cases.

Message-ID: <20230706075612.67404-2-david@redhat.com>
Acked-by: Peter Xu <peterx@redhat.com>
Tested-by: Mario Casquero <mcasquer@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: 836f657b6a32baf5579c6f218c9c104363562bb6
      
https://github.com/qemu/qemu/commit/836f657b6a32baf5579c6f218c9c104363562bb6
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

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

  Log Message:
  -----------
  virtio-mem: Skip most of virtio_mem_unplug_all() without plugged memory

Already when starting QEMU we perform one system reset that ends up
triggering virtio_mem_unplug_all() with no actual memory plugged yet.
That, in turn will trigger ram_block_discard_range() and perform some
other actions that are not required in that case.

Let's optimize virtio_mem_unplug_all() for the case that no memory is
plugged. This will be beneficial for x-ignore-shared support as well.

Message-ID: <20230706075612.67404-3-david@redhat.com>
Tested-by: Mario Casquero <mcasquer@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: f161c88a03c646ee308653d3ea99318901093309
      
https://github.com/qemu/qemu/commit/f161c88a03c646ee308653d3ea99318901093309
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M include/migration/misc.h
    M migration/postcopy-ram.c
    M migration/ram.c
    M migration/ram.h

  Log Message:
  -----------
  migration/ram: Expose ramblock_is_ignored() as migrate_ram_is_ignored()

virtio-mem wants to know whether it should not mess with the RAMBlock
content (e.g., discard RAM, preallocate memory) on incoming migration.

So let's expose that function as migrate_ram_is_ignored() in
migration/misc.h

Message-ID: <20230706075612.67404-4-david@redhat.com>
Acked-by: Peter Xu <peterx@redhat.com>
Tested-by: Mario Casquero <mcasquer@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: b01fd4b67a8fdf5a9ecf4ad5b49b70d52424f0f7
      
https://github.com/qemu/qemu/commit/b01fd4b67a8fdf5a9ecf4ad5b49b70d52424f0f7
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

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

  Log Message:
  -----------
  virtio-mem: Support "x-ignore-shared" migration

To achieve desired "x-ignore-shared" functionality, we should not
discard all RAM when realizing the device and not mess with
preallocation/postcopy when loading device state. In essence, we should
not touch RAM content.

As "x-ignore-shared" gets set after realizing the device, we cannot
rely on that. Let's simply skip discarding of RAM on incoming migration.
Note that virtio_mem_post_load() will call
virtio_mem_restore_unplugged() -- unless "x-ignore-shared" is set. So
once migration finished we'll have a consistent state.

The initial system reset will also not discard any RAM, because
virtio_mem_unplug_all() will not call virtio_mem_unplug_all() when no
memory is plugged (which is the case before loading the device state).

Note that something like VM templating -- see commit b17fbbe55cba
("migration: allow private destination ram with x-ignore-shared") -- is
currently incompatible with virtio-mem and ram_block_discard_range() will
warn in case a private file mapping is supplied by virtio-mem.

For VM templating with virtio-mem, it makes more sense to either
(a) Create the template without the virtio-mem device and hotplug a
    virtio-mem device to the new VM instances using proper own memory
    backend.
(b) Use a virtio-mem device that doesn't provide any memory in the
    template (requested-size=0) and use private anonymous memory.

Message-ID: <20230706075612.67404-5-david@redhat.com>
Tested-by: Mario Casquero <mcasquer@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: 18129c15bcefc0064febe2dc7759b93f7c5aaab3
      
https://github.com/qemu/qemu/commit/18129c15bcefc0064febe2dc7759b93f7c5aaab3
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M MAINTAINERS
    M hw/virtio/Kconfig
    M hw/virtio/meson.build
    A hw/virtio/virtio-md-pci.c
    M hw/virtio/virtio-mem-pci.c
    M hw/virtio/virtio-mem-pci.h
    M hw/virtio/virtio-pmem-pci.c
    M hw/virtio/virtio-pmem-pci.h
    A include/hw/virtio/virtio-md-pci.h

  Log Message:
  -----------
  virtio-md-pci: New parent type for virtio-mem-pci and virtio-pmem-pci

Let's add a new abstract "virtio memory device" type, and use it as
parent class of virtio-mem-pci and virtio-pmem-pci.

Message-ID: <20230711153445.514112-2-david@redhat.com>
Tested-by: Mario Casquero <mcasquer@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: dbdf841b2ed8b88d30a8a1f0c26029b2ebb93e76
      
https://github.com/qemu/qemu/commit/dbdf841b2ed8b88d30a8a1f0c26029b2ebb93e76
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M MAINTAINERS
    M hw/i386/pc.c
    M hw/virtio/virtio-md-pci.c
    M include/hw/virtio/virtio-md-pci.h
    M stubs/meson.build
    A stubs/virtio-md-pci.c

  Log Message:
  -----------
  pc: Factor out (un)plug handling of virtio-md-pci devices

Let's factor out (un)plug handling, to be reused from arm/virt code.

Provide stubs for the case that CONFIG_VIRTIO_MD is not selected because
neither virtio-mem nor virtio-pmem is enabled. While this cannot
currently happen for x86, it will be possible for arm/virt.

Message-ID: <20230711153445.514112-3-david@redhat.com>
Tested-by: Mario Casquero <mcasquer@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: 30ec5ccd3a2692464f832ec5a18b448d5ff86752
      
https://github.com/qemu/qemu/commit/30ec5ccd3a2692464f832ec5a18b448d5ff86752
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M hw/arm/virt.c

  Log Message:
  -----------
  arm/virt: Use virtio-md-pci (un)plug functions

Let's use our new helper functions. Note that virtio-pmem-pci is not
enabled for arm and, therefore, not compiled in.

Message-ID: <20230711153445.514112-4-david@redhat.com>
Tested-by: Mario Casquero <mcasquer@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: c29dd73f74fe6020ee0755d938885919a3719194
      
https://github.com/qemu/qemu/commit/c29dd73f74fe6020ee0755d938885919a3719194
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

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

  Log Message:
  -----------
  virtio-md-pci: Handle unplug of virtio based memory devices

While we fence unplug requests from the outside, the VM can still
trigger unplug of virtio based memory devices, for example, in Linux
doing on a virtio-mem-pci device:
    # echo 0 > /sys/bus/pci/slots/3/power

While doing that is not really expected to work without harming the
guest OS (e.g., removing a virtio-mem device while it still provides
memory), let's make sure that we properly handle it on the QEMU side.

We'll add support for unplugging of virtio-mem devices in some
configurations next.

Message-ID: <20230711153445.514112-5-david@redhat.com>
Tested-by: Mario Casquero <mcasquer@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: aac44204bc6d2a062c2e1658fe6a02a67f55b9e6
      
https://github.com/qemu/qemu/commit/aac44204bc6d2a062c2e1658fe6a02a67f55b9e6
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M hw/virtio/virtio-md-pci.c
    M include/hw/virtio/virtio-md-pci.h

  Log Message:
  -----------
  virtio-md-pci: Support unplug requests for compatible devices

Let's support unplug requests for virtio-md-pci devices that provide
a unplug_request_check() callback.

We'll wire that up for virtio-mem-pci next.

Message-ID: <20230711153445.514112-6-david@redhat.com>
Tested-by: Mario Casquero <mcasquer@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: 92a8ee1b594244a82d4c955eab907034f8953f8b
      
https://github.com/qemu/qemu/commit/92a8ee1b594244a82d4c955eab907034f8953f8b
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M hw/virtio/virtio-mem.c
    M include/hw/virtio/virtio-mem.h

  Log Message:
  -----------
  virtio-mem: Prepare for device unplug support

In many cases, blindly unplugging a virtio-mem device is problematic. We
can only safely remove a device once:
* The guest is not expecting to be able to read unplugged memory
  (unplugged-inaccessible == on)
* The virtio-mem device does not have memory plugged (size == 0)
* The virtio-mem device does not have outstanding requests to the VM to
  plug memory (requested-size == 0)

So let's add a callback to the virtio-mem device class to check for that.
We'll wire-up virtio-mem-pci next.

Message-ID: <20230711153445.514112-7-david@redhat.com>
Tested-by: Mario Casquero <mcasquer@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: 339a8bbdfed910d0baa392c2071fd0e09b30aed9
      
https://github.com/qemu/qemu/commit/339a8bbdfed910d0baa392c2071fd0e09b30aed9
  Author: David Hildenbrand <david@redhat.com>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

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

  Log Message:
  -----------
  virtio-mem-pci: Device unplug support

Let's support device unplug by forwarding the unplug_request_check()
callback to the virtio-mem device.

Further, disallow changing the requested-size once an unplug request is
pending.

Disallowing requested-size changes handles corner cases such as
(1) pausing the VM (2) requesting device unplug and (3) adjusting the
requested size. If the VM would plug memory (due to the requested size
change) before processing the unplug request, we would be in trouble.

Message-ID: <20230711153445.514112-8-david@redhat.com>
Tested-by: Mario Casquero <mcasquer@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>


  Commit: 6f05a92ddc73ac8aa16cfd6188f907b30b0501e3
      
https://github.com/qemu/qemu/commit/6f05a92ddc73ac8aa16cfd6188f907b30b0501e3
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2023-07-12 (Wed, 12 Jul 2023)

  Changed paths:
    M MAINTAINERS
    M hw/arm/virt.c
    M hw/i386/acpi-build.c
    M hw/i386/pc.c
    M hw/loongarch/virt.c
    M hw/mem/memory-device.c
    M hw/ppc/spapr.c
    M hw/ppc/spapr_hcall.c
    M hw/virtio/Kconfig
    M hw/virtio/meson.build
    A hw/virtio/virtio-md-pci.c
    M hw/virtio/virtio-mem-pci.c
    M hw/virtio/virtio-mem-pci.h
    M hw/virtio/virtio-mem.c
    M hw/virtio/virtio-pmem-pci.c
    M hw/virtio/virtio-pmem-pci.h
    M include/hw/boards.h
    M include/hw/i386/pc.h
    A include/hw/virtio/virtio-md-pci.h
    M include/hw/virtio/virtio-mem.h
    M include/migration/misc.h
    M migration/postcopy-ram.c
    M migration/ram.c
    M migration/ram.h
    M softmmu/physmem.c
    M stubs/meson.build
    A stubs/virtio-md-pci.c

  Log Message:
  -----------
  Merge tag 'mem-2023-07-12' of https://github.com/davidhildenbrand/qemu into 
staging

Hi,

"Host Memory Backends" and "Memory devices" queue ("mem"):
- Memory device cleanups (especially around machine initialization)
- "x-ignore-shared" migration support for virtio-mem
- Add an abstract virtio-md-pci device as a common parent for
  virtio-mem-pci and virtio-pmem-pci (virtio based memory devices)
- Device unplug support for virtio-mem-pci

# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAmSuYAQRHGRhdmlkQHJl
# ZGhhdC5jb20ACgkQTd4Q9wD/g1od9A/9HXT8IqKGup9is7P/mpobPWXczRGZ5sEg
# /q21PzX6crr9aFa+fYRF/Dlm3G/cSMOVXFRKGz3royLjsvaEj/veEewfKF8KWbBf
# eIS9udQTOwoD2kAhcv3pm0SwSJoVizpw2z7IodGVKE6iZxTXsmDksqQuFbrvVLSh
# 2wtP4lizEXco/YsiCoAnStj2QtXBcHw7Ua7W2cDzxFmL+1pM5w3rjQ1ydCNz3bSG
# l4CXXs1i8OmOZbFN78F/E9SEkzQnAuHSO0Sc1aeAJkwVzOt2lj/YMgt0jHjAY0at
# pheWZ5pEE6hnQP740YXpt4Y6IIgO22pH23dLhq9A2reyRnwjt830uObHi3qAE8kB
# KR+ZQ+Z5bI6ZNB/EFiUsC1dFsr2fF20zQlO02MctyJ+lUG6p3gpvwsGScQxt+zdF
# QlkiSecGErYwC+nZ529SQB4gSEJTCjd/STDoidVYnZazdStaOaSyft02xRNzBPW/
# OnOY+6ZxZK6R11KfwGjnsftrovQIP3Pqi9TXGzW2xVlkWJHqlicy6G3ZfceTTlj9
# Gg2Ue694Wr1r4PDV2XlYcZ1IPLjSy5Msp5V2wERRrp3OItxnvegvTevQN7USEHC+
# BPGNMu11jriSY2pE5BSFN0hfGOvuvsk3GreLJiHFUXoje6gzAynuLjCN/CHdIVyK
# 5i0AwdZ+xcA=
# =ch6m
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 12 Jul 2023 09:10:44 AM BST
# gpg:                using RSA key 1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A
# gpg:                issuer "david@redhat.com"
# gpg: Good signature from "David Hildenbrand <david@redhat.com>" [unknown]
# gpg:                 aka "David Hildenbrand <davidhildenbrand@gmail.com>" 
[undefined]
# gpg:                 aka "David Hildenbrand <hildenbr@in.tum.de>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 1BD9 CAAD 735C 4C3A 460D  FCCA 4DDE 10F7 00FF 835A

* tag 'mem-2023-07-12' of https://github.com/davidhildenbrand/qemu: (21 commits)
  virtio-mem-pci: Device unplug support
  virtio-mem: Prepare for device unplug support
  virtio-md-pci: Support unplug requests for compatible devices
  virtio-md-pci: Handle unplug of virtio based memory devices
  arm/virt: Use virtio-md-pci (un)plug functions
  pc: Factor out (un)plug handling of virtio-md-pci devices
  virtio-md-pci: New parent type for virtio-mem-pci and virtio-pmem-pci
  virtio-mem: Support "x-ignore-shared" migration
  migration/ram: Expose ramblock_is_ignored() as migrate_ram_is_ignored()
  virtio-mem: Skip most of virtio_mem_unplug_all() without plugged memory
  softmmu/physmem: Warn with ram_block_discard_range() on MAP_PRIVATE file 
mapping
  memory-device: Track used region size in DeviceMemoryState
  memory-device: Refactor memory_device_pre_plug()
  hw/i386/pc: Remove PC_MACHINE_DEVMEM_REGION_SIZE
  hw/i386/acpi-build: Rely on machine->device_memory when building SRAT
  hw/i386/pc: Use machine_memory_devices_init()
  hw/loongarch/virt: Use machine_memory_devices_init()
  hw/ppc/spapr: Use machine_memory_devices_init()
  hw/arm/virt: Use machine_memory_devices_init()
  memory-device: Introduce machine_memory_devices_init()
  ...

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


Compare: https://github.com/qemu/qemu/compare/887cba855bb6...6f05a92ddc73
[Prev in Thread]
Current Thread
[Next in Thread]
[Qemu-commits] [qemu/qemu] 99d88d: memory-device: Unify enabled vs. supported error m..., Richard Henderson <=
- [Qemu-commits] [qemu/qemu] 99d88d: memory-device: Unify enabled vs. supported error m..., Richard Henderson, 2023/07/12
Prev by Date: [Qemu-commits] [qemu/qemu] 887cba: configure: Fix cross-building for RISCV host (v5)
Next by Date: [Qemu-commits] [qemu/qemu] 99d88d: memory-device: Unify enabled vs. supported error m...
Previous by thread: [Qemu-commits] [qemu/qemu] 887cba: configure: Fix cross-building for RISCV host (v5)
Next by thread: [Qemu-commits] [qemu/qemu] 99d88d: memory-device: Unify enabled vs. supported error m...
Index(es):
- Date
- Thread