Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: 713484d0389c9d1cbb87eca060361281248b69f5
https://github.com/qemu/qemu/commit/713484d0389c9d1cbb87eca060361281248b69f5
Author: David Hildenbrand <[email protected]>
Date: 2024-12-21 (Sat, 21 Dec 2024)
Changed paths:
M hw/virtio/virtio-mem.c
M include/hw/virtio/virtio-mem.h
Log Message:
-----------
virtio-mem: unplug memory only during system resets, not device resets
We recently converted from the LegacyReset to the new reset framework
in commit c009a311e939 ("virtio-mem: Use new Resettable framework instead
of LegacyReset") to be able to use the ResetType to filter out wakeup
resets.
However, this change had an undesired implications: as we override the
Resettable interface methods in VirtIOMEMClass, the reset handler will
not only get called during system resets (i.e., qemu_devices_reset())
but also during any direct or indirect device rests (e.g.,
device_cold_reset()).
Further, we might now receive two reset callbacks during
qemu_devices_reset(), first when reset by a parent and later when reset
directly.
The memory state of virtio-mem devices is rather special: it's supposed to
be persistent/unchanged during most resets (similar to resetting a hard
disk will not destroy the data), unless actually cold-resetting the whole
system (different to a hard disk where a reboot will not destroy the data):
ripping out system RAM is something guest OSes don't particularly enjoy,
but we want to detect when rebooting to an OS that does not support
virtio-mem and wouldn't be able to detect+use the memory -- and we want
to force-defragment hotplugged memory to also shrink the usable device
memory region. So we rally want to catch system resets to do that.
On supported targets (e.g., x86), getting a cold reset on the
device/parent triggers is not that easy (but looks like PCI code
might trigger it), so this implication went unnoticed.
However, with upcoming s390x support it is problematic: during
kdump, s390x triggers a subsystem reset, ending up in
s390_machine_reset() and calling only subsystem_reset() instead of
qemu_devices_reset() -- because it's not a full system reset.
In subsystem_reset(), s390x performs a device_cold_reset() of any
TYPE_VIRTUAL_CSS_BRIDGE device, which ends up resetting all children,
including the virtio-mem device. Consequently, we wrongly detect a system
reset and unplug all device memory, resulting in hotplugged memory not
getting included in the crash dump -- undesired.
We really must not mess with hotplugged memory state during simple
device resets. To fix, create+register a new reset object that will only
get triggered during qemu_devices_reset() calls, but not during any other
resets as it is logically not the child of any other object.
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Cc: "Michael S. Tsirkin" <[email protected]>
Cc: Juraj Marcin <[email protected]>
Cc: Peter Maydell <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
Commit: 14e568ab4836347481af2e334009c385f456a734
https://github.com/qemu/qemu/commit/14e568ab4836347481af2e334009c385f456a734
Author: David Hildenbrand <[email protected]>
Date: 2024-12-21 (Sat, 21 Dec 2024)
Changed paths:
M hw/s390x/s390-virtio-ccw.c
Log Message:
-----------
s390x/s390-virtio-ccw: don't crash on weird RAM sizes
KVM is not happy when starting a VM with weird RAM sizes:
# qemu-system-s390x --enable-kvm --nographic -m 1234K
qemu-system-s390x: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION
failed, slot=0, start=0x0, size=0x244000: Invalid argument
kvm_set_phys_mem: error registering slot: Invalid argument
Aborted (core dumped)
Let's handle that in a better way by rejecting such weird RAM sizes
right from the start:
# qemu-system-s390x --enable-kvm --nographic -m 1234K
qemu-system-s390x: ram size must be multiples of 1 MiB
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Eric Farman <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Acked-by: Janosch Frank <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
Commit: 4be0fce498d0a08f18b3a9accdb9ded79484d30a
https://github.com/qemu/qemu/commit/4be0fce498d0a08f18b3a9accdb9ded79484d30a
Author: David Hildenbrand <[email protected]>
Date: 2024-12-21 (Sat, 21 Dec 2024)
Changed paths:
M hw/s390x/meson.build
M hw/s390x/s390-virtio-ccw.c
M hw/s390x/s390-virtio-hcall.c
M hw/s390x/s390-virtio-hcall.h
M target/s390x/kvm/kvm.c
M target/s390x/tcg/misc_helper.c
Log Message:
-----------
s390x/s390-virtio-hcall: remove hypercall registration mechanism
Nowadays, we only have a single machine type in QEMU, everything is based
on virtio-ccw and the traditional virtio machine does no longer exist. No
need to dynamically register diag500 handlers. Move the two existing
handlers into s390-virtio-hcall.c.
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Acked-by: Christian Borntraeger <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
Commit: 6e9cc2da4e8b997fd6ff3249034f436b84fc7974
https://github.com/qemu/qemu/commit/6e9cc2da4e8b997fd6ff3249034f436b84fc7974
Author: David Hildenbrand <[email protected]>
Date: 2024-12-21 (Sat, 21 Dec 2024)
Changed paths:
M hw/s390x/s390-virtio-hcall.c
M hw/s390x/s390-virtio-hcall.h
M target/s390x/kvm/kvm.c
M target/s390x/tcg/misc_helper.c
Log Message:
-----------
s390x/s390-virtio-hcall: prepare for more diag500 hypercalls
Let's generalize, abstracting the virtio bits. diag500 is now a generic
hypercall to handle QEMU/KVM specific things. Explicitly specify all
already defined subcodes, including legacy ones (so we know what we can
use for new hypercalls).
Move the PGM_SPECIFICATION injection into the renamed function
handle_diag_500(), so we can turn it into a void function.
We'll rename the files separately, so git properly detects the rename.
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
Commit: 85489fc3652d0c4433c940f1a80a952e8cb5d3cb
https://github.com/qemu/qemu/commit/85489fc3652d0c4433c940f1a80a952e8cb5d3cb
Author: David Hildenbrand <[email protected]>
Date: 2024-12-21 (Sat, 21 Dec 2024)
Changed paths:
M hw/s390x/meson.build
A hw/s390x/s390-hypercall.c
A hw/s390x/s390-hypercall.h
R hw/s390x/s390-virtio-hcall.c
R hw/s390x/s390-virtio-hcall.h
M target/s390x/kvm/kvm.c
M target/s390x/tcg/misc_helper.c
Log Message:
-----------
s390x: rename s390-virtio-hcall* to s390-hypercall*
Let's make it clearer that we are talking about general
QEMU/KVM-specific hypercalls.
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
Commit: 3c6fb557d295949bea291c3bf88ee9c83392e78c
https://github.com/qemu/qemu/commit/3c6fb557d295949bea291c3bf88ee9c83392e78c
Author: David Hildenbrand <[email protected]>
Date: 2024-12-21 (Sat, 21 Dec 2024)
Changed paths:
M hw/s390x/s390-virtio-ccw.c
M hw/s390x/sclp.c
M target/s390x/kvm/pv.c
Log Message:
-----------
s390x/s390-virtio-ccw: move setting the maximum guest size from sclp to
machine code
Nowadays, it feels more natural to have that code located in
s390_memory_init(), where we also have direct access to the machine
object.
While at it, use the actual RAM size, not the maximum RAM size which
cannot currently be reached without support for any memory devices.
Consequently update s390_pv_vm_try_disable_async() to rely on the RAM size
as well, to avoid temporary issues while we further rework that
handling.
set_memory_limit() is temporary, we'll merge it with
s390_set_memory_limit() next.
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
Commit: 27221b69a3ea49339a1f82b9622126f3928e0915
https://github.com/qemu/qemu/commit/27221b69a3ea49339a1f82b9622126f3928e0915
Author: David Hildenbrand <[email protected]>
Date: 2024-12-21 (Sat, 21 Dec 2024)
Changed paths:
M hw/s390x/s390-virtio-ccw.c
M include/hw/s390x/s390-virtio-ccw.h
M target/s390x/cpu-sysemu.c
M target/s390x/cpu.h
Log Message:
-----------
s390x: introduce s390_get_memory_limit()
Let's add s390_get_memory_limit(), to query what has been successfully
set via s390_set_memory_limit(). Allow setting the limit only once.
We'll remember the limit in the machine state. Move
s390_set_memory_limit() to machine code, merging it into
set_memory_limit(), because this really is a machine property.
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
Commit: f7c168657816486527727d860b73747d41f0c5f6
https://github.com/qemu/qemu/commit/f7c168657816486527727d860b73747d41f0c5f6
Author: David Hildenbrand <[email protected]>
Date: 2024-12-21 (Sat, 21 Dec 2024)
Changed paths:
M hw/s390x/s390-hypercall.c
M hw/s390x/s390-hypercall.h
Log Message:
-----------
s390x/s390-hypercall: introduce DIAG500 STORAGE_LIMIT
A guest OS that supports memory hotplug / memory devices must during
boot be aware of the maximum possible physical memory address that it might
have to handle at a later stage during its runtime.
For example, the maximum possible memory address might be required to
prepare the kernel virtual address space accordingly (e.g., select page
table hierarchy depth).
On s390x there is currently no such mechanism that is compatible with
paravirtualized memory devices, because the whole SCLP interface was
designed around the idea of "storage increments" and "standby memory".
Paravirtualized memory devices we want to support, such as virtio-mem, have
no intersection with any of that, but could co-exist with them in the
future if ever needed.
In particular, a guest OS must never detect and use device memory
without the help of a proper device driver. Device memory must not be
exposed in any firmware-provided memory map (SCLP or diag260 on s390x).
For this reason, these memory devices will be places in memory *above*
the "maximum storage increment" exposed via SCLP.
Let's provide a new diag500 subcode to query the memory limit determined in
s390_memory_init().
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
Commit: 241e6b2d27b090b17cda5b011b2064544b0c458b
https://github.com/qemu/qemu/commit/241e6b2d27b090b17cda5b011b2064544b0c458b
Author: David Hildenbrand <[email protected]>
Date: 2024-12-21 (Sat, 21 Dec 2024)
Changed paths:
M hw/s390x/s390-stattrib-kvm.c
Log Message:
-----------
s390x/s390-stattrib-kvm: prepare for memory devices and sparse memory layouts
With memory devices, we will have storage attributes for memory that
exceeds the initial ram size. Further, we can easily have memory holes,
for which there (currently) are no storage attributes.
In particular, with memory holes, KVM_S390_SET_CMMA_BITS will fail to set
some storage attributes.
So let's do it like we handle storage keys migration, relying on
guest_phys_blocks_append(). However, in contrast to storage key
migration, we will handle it on the migration destination.
This is a preparation for virtio-mem support. Note that ever since the
"early migration" feature was added (x-early-migration), the state
of device blocks (plugged/unplugged) is migrated early such that
guest_phys_blocks_append() will properly consider all currently plugged
memory blocks and skip any unplugged ones.
In the future, we should try getting rid of the large temporary buffer
and also not send any attributes for any memory holes, just so they
get ignored on the destination.
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
Commit: d1e3c2ac41b3f73708682e4e8212c32ad35013b9
https://github.com/qemu/qemu/commit/d1e3c2ac41b3f73708682e4e8212c32ad35013b9
Author: David Hildenbrand <[email protected]>
Date: 2024-12-21 (Sat, 21 Dec 2024)
Changed paths:
M hw/s390x/s390-skeys.c
Log Message:
-----------
s390x/s390-skeys: prepare for memory devices
With memory devices, we will have storage keys for memory that
exceeds the initial ram size.
The TODO already states that current handling is subopimal,
but we won't worry about improving that (TCG-only) thing for now.
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
Commit: 1e86400298cf0fed5f7d49427db477775b859093
https://github.com/qemu/qemu/commit/1e86400298cf0fed5f7d49427db477775b859093
Author: David Hildenbrand <[email protected]>
Date: 2024-12-21 (Sat, 21 Dec 2024)
Changed paths:
M hw/s390x/s390-virtio-ccw.c
M hw/s390x/sclp.c
Log Message:
-----------
s390x/s390-virtio-ccw: prepare for memory devices
Let's prepare our address space for memory devices if enabled via
"maxmem" and if we have CONFIG_MEM_DEVICE enabled at all. Note that
CONFIG_MEM_DEVICE will be selected automatically once we add support
for devices.
Just like on other architectures, the region container for memory devices
is placed directly above our initial memory. For now, we only align the
start address of the region up to 1 GiB, but we won't add any additional
space to the region for internal alignment purposes; this can be done in
the future if really required.
The RAM size returned via SCLP is not modified, as this only
covers initial RAM (and standby memory we don't implement) and not memory
devices; clarify that in the docs of read_SCP_info(). Existing OSes without
support for memory devices will keep working as is, even when memory
devices would be attached the VM.
Guest OSs which support memory devices, such as virtio-mem, will
consult diag500(), to find out the maximum possible pfn. Guest OSes that
don't support memory devices, don't have to be changed and will continue
relying on information provided by SCLP.
There are no remaining maxram_size users in s390x code, and the remaining
ram_size users only care about initial RAM:
* hw/s390x/ipl.c
* hw/s390x/s390-hypercall.c
* hw/s390x/sclp.c
* target/s390x/kvm/pv.c
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
Commit: a056332e732110c8ef0d40ffd49bd03afc2f04ca
https://github.com/qemu/qemu/commit/a056332e732110c8ef0d40ffd49bd03afc2f04ca
Author: David Hildenbrand <[email protected]>
Date: 2024-12-21 (Sat, 21 Dec 2024)
Changed paths:
M target/s390x/kvm/pv.c
Log Message:
-----------
s390x/pv: prepare for memory devices
Let's avoid checking for the maxram_size, and instead rely on the memory
limit determined in s390_memory_init(), that might be larger than
maxram_size, for example due to alignment purposes.
This check now correctly mimics what the kernel will check in
kvm_s390_pv_set_aside(), whereby a VM <= 2 GiB VM would end up using
a segment type ASCE.
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Nina Schoetterl-Glausch <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
Commit: df2ac211a62e6ced7f1495b634fa6f78962f2321
https://github.com/qemu/qemu/commit/df2ac211a62e6ced7f1495b634fa6f78962f2321
Author: David Hildenbrand <[email protected]>
Date: 2024-12-21 (Sat, 21 Dec 2024)
Changed paths:
M hw/s390x/s390-virtio-ccw.c
M include/hw/s390x/s390-virtio-ccw.h
M target/s390x/cpu-sysemu.c
M target/s390x/cpu.h
Log Message:
-----------
s390x: remember the maximum page size
Let's remember the value (successfully) set via s390_set_max_pagesize().
This will be helpful to reject hotplugged memory devices that would exceed
this initially set page size.
Handle it just like how we handle s390_get_memory_limit(), storing it in
the machine, and moving the handling to machine code.
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
Commit: 88d86f6f1e36741ba9e1625da19a7ccf1a343d39
https://github.com/qemu/qemu/commit/88d86f6f1e36741ba9e1625da19a7ccf1a343d39
Author: David Hildenbrand <[email protected]>
Date: 2024-12-21 (Sat, 21 Dec 2024)
Changed paths:
M MAINTAINERS
M hw/s390x/meson.build
M hw/s390x/s390-virtio-ccw.c
A hw/s390x/virtio-ccw-md-stubs.c
A hw/s390x/virtio-ccw-md.c
A hw/s390x/virtio-ccw-md.h
M hw/virtio/Kconfig
Log Message:
-----------
s390x/virtio-ccw: add support for virtio based memory devices
Let's implement support for abstract virtio based memory devices, using
the virtio-pci implementation as an orientation. Wire them up in the
machine hotplug handler, taking care of s390x page size limitations.
As we neither support virtio-mem or virtio-pmem yet, the code is
effectively unused. We'll implement support for virtio-mem based on this
next.
Note that we won't wire up the virtio-pci variant (should currently be
impossible due to lack of support for MSI-X), but we'll add a safety net
to reject plugging them in the pre-plug handler.
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
Commit: aa910c20ec5f3b10551da19e441b3e2b54406e25
https://github.com/qemu/qemu/commit/aa910c20ec5f3b10551da19e441b3e2b54406e25
Author: David Hildenbrand <[email protected]>
Date: 2024-12-21 (Sat, 21 Dec 2024)
Changed paths:
M MAINTAINERS
M hw/s390x/Kconfig
M hw/s390x/meson.build
A hw/s390x/virtio-ccw-mem.c
A hw/s390x/virtio-ccw-mem.h
M hw/virtio/virtio-mem.c
Log Message:
-----------
s390x: virtio-mem support
Let's add our virtio-mem-ccw proxy device and wire it up. We should
be supporting everything (e.g., device unplug, "dynamic-memslots") that
we already support for the virtio-pci variant.
With a Linux guest that supports virtio-mem (and has automatic memory
onlining properly configured) the following example will work:
1. Start a VM with 4G initial memory and a virtio-mem device with a maximum
capacity of 16GB:
qemu/build/qemu-system-s390x \
--enable-kvm \
-m 4G,maxmem=20G \
-nographic \
-smp 8 \
-hda Fedora-Server-KVM-40-1.14.s390x.qcow2 \
-chardev socket,id=monitor,path=/var/tmp/monitor,server,nowait \
-mon chardev=monitor,mode=readline \
-object memory-backend-ram,id=mem0,size=16G,reserve=off \
-device virtio-mem-ccw,id=vmem0,memdev=mem0,dynamic-memslots=on
2. Query the current size of virtio-mem device:
(qemu) info memory-devices
Memory device [virtio-mem]: "vmem0"
memaddr: 0x100000000
node: 0
requested-size: 0
size: 0
max-size: 17179869184
block-size: 1048576
memdev: /objects/mem0
3. Request to grow it to 8GB (hotplug 8GB):
(qemu) qom-set vmem0 requested-size 8G
(qemu) info memory-devices
Memory device [virtio-mem]: "vmem0"
memaddr: 0x100000000
node: 0
requested-size: 8589934592
size: 8589934592
max-size: 17179869184
block-size: 1048576
memdev: /objects/mem0
4. Request to grow to 16GB (hotplug another 8GB):
(qemu) qom-set vmem0 requested-size 16G
(qemu) info memory-devices
Memory device [virtio-mem]: "vmem0"
memaddr: 0x100000000
node: 0
requested-size: 17179869184
size: 17179869184
max-size: 17179869184
block-size: 1048576
memdev: /objects/mem0
5. Try to hotunplug all memory again, shrinking to 0GB:
(qemu) qom-set vmem0 requested-size 0G
(qemu) info memory-devices
Memory device [virtio-mem]: "vmem0"
memaddr: 0x100000000
node: 0
requested-size: 0
size: 0
max-size: 17179869184
block-size: 1048576
memdev: /objects/mem0
6. If it worked, unplug the device
(qemu) device_del vmem0
(qemu) info memory-devices
(qemu) object_del mem0
7. Hotplug a new device with a smaller capacity and directly size it to 1GB
(qemu) object_add memory-backend-ram,id=mem0,size=8G,reserve=off
(qemu) device_add virtio-mem-ccw,id=vmem0,memdev=mem0,\
dynamic-memslots=on,requested-size=1G
(qemu) info memory-devices
Memory device [virtio-mem]: "vmem0"
memaddr: 0x100000000
node: 0
requested-size: 1073741824
size: 1073741824
max-size: 8589934592
block-size: 1048576
memdev: /objects/mem0
Trying to use a virtio-mem device backed by hugetlb into a !hugetlb VM
correctly results in the error:
... Memory device uses a bigger page size than initial memory
Note that the virtio-mem driver in Linux will supports 1 MiB (pageblock)
granularity.
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
Commit: aa3a285b5bc56a4208b3b57d4a55291e9c260107
https://github.com/qemu/qemu/commit/aa3a285b5bc56a4208b3b57d4a55291e9c260107
Author: Stefan Hajnoczi <[email protected]>
Date: 2024-12-22 (Sun, 22 Dec 2024)
Changed paths:
M MAINTAINERS
M hw/s390x/Kconfig
M hw/s390x/meson.build
A hw/s390x/s390-hypercall.c
A hw/s390x/s390-hypercall.h
M hw/s390x/s390-skeys.c
M hw/s390x/s390-stattrib-kvm.c
M hw/s390x/s390-virtio-ccw.c
R hw/s390x/s390-virtio-hcall.c
R hw/s390x/s390-virtio-hcall.h
M hw/s390x/sclp.c
A hw/s390x/virtio-ccw-md-stubs.c
A hw/s390x/virtio-ccw-md.c
A hw/s390x/virtio-ccw-md.h
A hw/s390x/virtio-ccw-mem.c
A hw/s390x/virtio-ccw-mem.h
M hw/virtio/Kconfig
M hw/virtio/virtio-mem.c
M include/hw/s390x/s390-virtio-ccw.h
M include/hw/virtio/virtio-mem.h
M target/s390x/cpu-system.c
M target/s390x/cpu.h
M target/s390x/kvm/kvm.c
M target/s390x/kvm/pv.c
M target/s390x/tcg/misc_helper.c
Log Message:
-----------
Merge tag 'mem-2024-12-21' of https://github.com/davidhildenbrand/qemu into
staging
Hi,
"Host Memory Backends" and "Memory devices" queue ("mem"):
- Fixup handling of virtio-mem unplug during system resets, as
preparation for s390x support (especially kdump in the Linux guest)
- virtio-mem support for s390x
# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAmdnFD4RHGRhdmlkQHJl
# ZGhhdC5jb20ACgkQTd4Q9wD/g1rWBBAAp7WkYaNAjRy1PgpjNZ3z1gUJc/vk+skJ
# xVgGodA8txrJOFpNrbTyfhrdLs2TV4oWDvB/zrZRRtuxvur3O1EhFd9k6EqXuydr
# 0FunvLvVJwRHfEZycjN4aacQMRH3CJw07OaTzexeSl5UR/6w5PRofwUK4HX7W/Ka
# arqomGa3OJrs1+WgkV0Qcn4vh9HLRVv3iNC2Xo4W1wOCr1Du9zSPn9oC7zOQ0EO4
# ZC//7QsdkNRjUX/yMXMkhlSXx3b/RmRg2DBrxo7BZXg27VwGu4uHxL4LRBZiB2A7
# V9MqFOcVKzPMkXKTRjrgZ0vXQx1MPJ6WprEihMzMpYU6DrpA7KN/l8Ca8H24B2ln
# h7+bmkDsHVVcWovE9ii/9cMRfws6uWXXg3KoA8RQ8IbX1tU02lblw2uHhXEzcoge
# npqp/Z5LAiKVMetEnNnLH5thjut5PAEjuqD00cmZAMy4DNngLX2bGSdzMeVBkDMa
# 78ehLGRplm3t7ibUfaZaMKe6UD9tFrcD6XKsvUTXXHNbYO8ynbx58WOxSZmY98zU
# n3JNQRqtXYjBVlH3Dqm47vOTZHgOzFv3raa8BmSLpcBDeTXCTcUIl20s77dGw/vT
# r5YNCMN7O4YPFKUoRK9604QTgw6qlYaRTQlJD09usprGqVylb6gQtfZZuZkYDMp8
# sEI77QHsePA=
# =HDxr
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 21 Dec 2024 14:17:18 EST
# gpg: using RSA key 1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A
# gpg: issuer "[email protected]"
# gpg: Good signature from "David Hildenbrand <[email protected]>" [unknown]
# gpg: aka "David Hildenbrand <[email protected]>"
[full]
# gpg: aka "David Hildenbrand <[email protected]>" [unknown]
# gpg: WARNING: The key's User ID 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-2024-12-21' of https://github.com/davidhildenbrand/qemu:
s390x: virtio-mem support
s390x/virtio-ccw: add support for virtio based memory devices
s390x: remember the maximum page size
s390x/pv: prepare for memory devices
s390x/s390-virtio-ccw: prepare for memory devices
s390x/s390-skeys: prepare for memory devices
s390x/s390-stattrib-kvm: prepare for memory devices and sparse memory layouts
s390x/s390-hypercall: introduce DIAG500 STORAGE_LIMIT
s390x: introduce s390_get_memory_limit()
s390x/s390-virtio-ccw: move setting the maximum guest size from sclp to
machine code
s390x: rename s390-virtio-hcall* to s390-hypercall*
s390x/s390-virtio-hcall: prepare for more diag500 hypercalls
s390x/s390-virtio-hcall: remove hypercall registration mechanism
s390x/s390-virtio-ccw: don't crash on weird RAM sizes
virtio-mem: unplug memory only during system resets, not device resets
Conflicts:
- hw/s390x/s390-stattrib-kvm.c
sysemu/ -> system/ header rename conflict.
- hw/s390x/virtio-ccw-mem.c
Make Property array const and removed DEFINE_PROP_END_OF_LIST() to
conform to the latest conventions.
Signed-off-by: Stefan Hajnoczi <[email protected]>
Compare: https://github.com/qemu/qemu/compare/65cb7129f416...aa3a285b5bc5
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
