aboutsummaryrefslogtreecommitdiff
path: root/hw/s390x
AgeCommit message (Collapse)AuthorFilesLines
6 daysMerge tag 'mem-2024-12-21' of https://github.com/davidhildenbrand/qemu into ↵Stefan Hajnoczi15-159/+758
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 "david@redhat.com" # gpg: Good signature from "David Hildenbrand <david@redhat.com>" [unknown] # gpg: aka "David Hildenbrand <davidhildenbrand@gmail.com>" [full] # gpg: aka "David Hildenbrand <hildenbr@in.tum.de>" [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 <stefanha@redhat.com>
7 dayss390x: virtio-mem supportDavid Hildenbrand4-0/+262
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: <20241219144115.2820241-15-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
7 daysMerge tag 'exec-20241220' of https://github.com/philmd/qemu into stagingStefan Hajnoczi14-24/+24
Accel & Exec patch queue - Ignore writes to CNTP_CTL_EL0 on HVF ARM (Alexander) - Add '-d invalid_mem' logging option (Zoltan) - Create QOM containers explicitly (Peter) - Rename sysemu/ -> system/ (Philippe) - Re-orderning of include/exec/ headers (Philippe) Move a lot of declarations from these legacy mixed bag headers: . "exec/cpu-all.h" . "exec/cpu-common.h" . "exec/cpu-defs.h" . "exec/exec-all.h" . "exec/translate-all" to these more specific ones: . "exec/page-protection.h" . "exec/translation-block.h" . "user/cpu_loop.h" . "user/guest-host.h" . "user/page-protection.h" # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmdlnyAACgkQ4+MsLN6t # wN6mBw//QFWi7CrU+bb8KMM53kOU9C507tjn99LLGFb5or73/umDsw6eo/b8DHBt # KIwGLgATel42oojKfNKavtAzLK5rOrywpboPDpa3SNeF1onW+99NGJ52LQUqIX6K # A6bS0fPdGG9ZzEuPpbjDXlp++0yhDcdSgZsS42fEsT7Dyj5gzJYlqpqhiXGqpsn8 # 4Y0UMxSL21K3HEexlzw2hsoOBFA3tUm2ujNDhNkt8QASr85yQVLCypABJnuoe/// # 5Ojl5wTBeDwhANET0rhwHK8eIYaNboiM9fHopJYhvyw1bz6yAu9jQwzF/MrL3s/r # xa4OBHBy5mq2hQV9Shcl3UfCQdk/vDaYaWpgzJGX8stgMGYfnfej1SIl8haJIfcl # VMX8/jEFdYbjhO4AeGRYcBzWjEJymkDJZoiSWp2NuEDi6jqIW+7yW1q0Rnlg9lay # ShAqLK5Pv4zUw3t0Jy3qv9KSW8sbs6PQxtzXjk8p97rTf76BJ2pF8sv1tVzmsidP # 9L92Hv5O34IqzBu2oATOUZYJk89YGmTIUSLkpT7asJZpBLwNM2qLp5jO00WVU0Sd # +kAn324guYPkko/TVnjC/AY7CMu55EOtD9NU35k3mUAnxXT9oDUeL4NlYtfgrJx6 # x1Nzr2FkS68+wlPAFKNSSU5lTjsjNaFM0bIJ4LCNtenJVP+SnRo= # =cjz8 # -----END PGP SIGNATURE----- # gpg: Signature made Fri 20 Dec 2024 11:45:20 EST # gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [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: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE * tag 'exec-20241220' of https://github.com/philmd/qemu: (59 commits) util/qemu-timer: fix indentation meson: Do not define CONFIG_DEVICES on user emulation system/accel-ops: Remove unnecessary 'exec/cpu-common.h' header system/numa: Remove unnecessary 'exec/cpu-common.h' header hw/xen: Remove unnecessary 'exec/cpu-common.h' header target/mips: Drop left-over comment about Jazz machine target/mips: Remove tswap() calls in semihosting uhi_fstat_cb() target/xtensa: Remove tswap() calls in semihosting simcall() helper accel/tcg: Un-inline translator_is_same_page() accel/tcg: Include missing 'exec/translation-block.h' header accel/tcg: Move tcg_cflags_has/set() to 'exec/translation-block.h' accel/tcg: Restrict curr_cflags() declaration to 'internal-common.h' qemu/coroutine: Include missing 'qemu/atomic.h' header exec/translation-block: Include missing 'qemu/atomic.h' header accel/tcg: Declare cpu_loop_exit_requested() in 'exec/cpu-common.h' exec/cpu-all: Include 'cpu.h' earlier so MMU_USER_IDX is always defined target/sparc: Move sparc_restore_state_to_opc() to cpu.c target/sparc: Uninline cpu_get_tb_cpu_state() target/loongarch: Declare loongarch_cpu_dump_state() locally user: Move various declarations out of 'exec/exec-all.h' ... Conflicts: hw/char/riscv_htif.c hw/intc/riscv_aplic.c target/s390x/cpu.c Apply sysemu header path changes to not in the pull request. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
7 dayss390x/virtio-ccw: add support for virtio based memory devicesDavid Hildenbrand5-1/+270
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: <20241219144115.2820241-14-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
7 dayss390x: remember the maximum page sizeDavid Hildenbrand1-1/+11
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: <20241219144115.2820241-13-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
7 dayss390x/s390-virtio-ccw: prepare for memory devicesDavid Hildenbrand2-2/+27
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: <20241219144115.2820241-11-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
7 dayss390x/s390-skeys: prepare for memory devicesDavid Hildenbrand1-3/+3
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: <20241219144115.2820241-10-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
7 dayss390x/s390-stattrib-kvm: prepare for memory devices and sparse memory layoutsDavid Hildenbrand1-24/+43
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: <20241219144115.2820241-9-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
7 dayss390x/s390-hypercall: introduce DIAG500 STORAGE_LIMITDavid Hildenbrand2-1/+12
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: <20241219144115.2820241-8-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
7 dayss390x: introduce s390_get_memory_limit()David Hildenbrand1-5/+12
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: <20241219144115.2820241-7-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
7 dayss390x/s390-virtio-ccw: move setting the maximum guest size from sclp to ↵David Hildenbrand2-15/+24
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: <20241219144115.2820241-6-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
7 dayss390x: rename s390-virtio-hcall* to s390-hypercall*David Hildenbrand3-5/+5
Let's make it clearer that we are talking about general QEMU/KVM-specific hypercalls. Message-ID: <20241219144115.2820241-5-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
7 dayss390x/s390-virtio-hcall: prepare for more diag500 hypercallsDavid Hildenbrand2-12/+14
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: <20241219144115.2820241-4-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
7 dayss390x/s390-virtio-hcall: remove hypercall registration mechanismDavid Hildenbrand4-78/+53
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: <20241219144115.2820241-3-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: David Hildenbrand <david@redhat.com>
7 dayss390x/s390-virtio-ccw: don't crash on weird RAM sizesDavid Hildenbrand1-0/+11
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: <20241219144115.2820241-2-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: David Hildenbrand <david@redhat.com>
8 dayssystem: Move 'exec/confidential-guest-support.h' to system/Philippe Mathieu-Daudé1-1/+1
"exec/confidential-guest-support.h" is specific to system emulation, so move it under the system/ namespace. Mechanical change doing: $ sed -i \ -e 's,exec/confidential-guest-support.h,sysemu/confidential-guest-support.h,' \ $(git grep -l exec/confidential-guest-support.h) Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20241218155913.72288-2-philmd@linaro.org>
8 daysinclude: Rename sysemu/ -> system/Philippe Mathieu-Daudé14-23/+23
Headers in include/sysemu/ are not only related to system *emulation*, they are also used by virtualization. Rename as system/ which is clearer. Files renamed manually then mechanical change using sed tool. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Lei Yang <leiyang@redhat.com> Message-Id: <20241203172445.28576-1-philmd@linaro.org>
9 daysConstify all opaque Property pointersRichard Henderson2-4/+4
Via sed "s/ Property [*]/ const Property */". The opaque pointers passed to ObjectProperty callbacks are the last instances of non-const Property pointers in the tree. For the most part, these callbacks only use object_field_prop_ptr, which now takes a const pointer itself. This logically should have accompanied d36f165d952 which allowed const Property to be registered. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Lei Yang <leiyang@redhat.com> Link: https://lore.kernel.org/r/20241218134251.4724-25-richard.henderson@linaro.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
9 daysinclude/hw/qdev-properties: Remove DEFINE_PROP_END_OF_LISTRichard Henderson19-19/+0
Now that all of the Property arrays are counted, we can remove the terminator object from each array. Update the assertions in device_class_set_props to match. With struct Property being 88 bytes, this was a rather large form of terminator. Saves 30k from qemu-system-aarch64. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Lei Yang <leiyang@redhat.com> Link: https://lore.kernel.org/r/20241218134251.4724-21-richard.henderson@linaro.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
9 dayshw/s390x: Remove empty Property listsRichard Henderson1-5/+0
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Lei Yang <leiyang@redhat.com> Link: https://lore.kernel.org/r/20241218134251.4724-9-richard.henderson@linaro.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
13 dayshw/s390x: Constify all PropertyRichard Henderson19-19/+19
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-12-11hw: add compat machines for 10.0Cornelia Huck1-1/+13
Add 10.0 machine types for arm/i440fx/m68k/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20241126103005.3794748-3-cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-11-18hw: Add "loadparm" property to scsi disk devices for booting on s390xThomas Huth1-13/+6
While adding the new flexible boot order feature on s390x recently, we missed to add the "loadparm" property to the scsi-hd and scsi-cd devices. This property is required on s390x to pass the information to the boot loader about which kernel should be started or whether the boot menu should be shown. But even more serious: The missing property is now causing trouble with the corresponding libvirt patches that assume that the "loadparm" property is either settable for all bootable devices (when the "boot order" feature is implemented in QEMU), or none (meaning the behaviour of older QEMUs that only allowed one "loadparm" at the machine level). To fix this broken situation, let's implement the "loadparm" property in for the SCSI devices, too. Message-ID: <20241115141202.1877294-1-thuth@redhat.com> Acked-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-11-18hw/s390x: Restrict "loadparm" property to devices that can be used for bootingThomas Huth4-3/+8
Commit bb185de423 ("s390x: Add individual loadparm assignment to CCW device") added a "loadparm" property to all CCW devices. This was a little bit unfortunate, since this property is only useful for devices that can be used for booting, but certainly it is not useful for devices like virtio-gpu or virtio-tablet. Thus let's restrict the property to CCW devices that we can boot from (i.e. virtio-block, virtio-net and vfio-ccw devices). Message-ID: <20241113114741.681096-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Jared Rossi <jrossi@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-11-04hw/s390x: Re-enable the pci-bridge device on s390xThomas Huth1-0/+1
Commit e779e5c05a ("hw/pci-bridge: Add a Kconfig switch for the normal PCI bridge") added a config switch for the pci-bridge, so that the device is not included in the s390x target anymore (since the pci-bridge is not really useful on s390x). However, it seems like libvirt is still adding pci-bridge devices automatically to the guests' XML definitions (when adding a PCI device to a non-zero PCI bus), so these guests are now broken due to the missing pci-bridge in the QEMU binary. To avoid disruption of the users, let's re-enable the pci-bridge device on s390x for the time being. Message-ID: <20241024130405.62134-1-thuth@redhat.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23s390x: Rebuild IPLB for SCSI device directly from DIAG308Jared Rossi2-65/+20
Because virtio-scsi type devices use a non-architected IPLB pbt code they cannot be set and stored normally. Instead, the IPLB must be rebuilt during re-ipl. As s390x does not natively support multiple boot devices, the devno field is used to store the position in the boot order for the device. Handling the rebuild as part of DIAG308 removes the need to check the devices for invalid IPLBs later in the IPL. Signed-off-by: Jared Rossi <jrossi@linux.ibm.com> Acked-by: Thomas Huth <thuth@redhat.com> Message-ID: <20241020012953.1380075-17-jrossi@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23hw/s390x: Build an IPLB for each boot deviceJared Rossi2-28/+102
Build an IPLB for any device with a bootindex (up to a maximum of 8 devices). The IPLB chain is placed immediately before the BIOS in memory. Because this is not a fixed address, the location of the next IPLB and number of remaining boot devices is stored in the QIPL global variable for possible later access by the guest during IPL. Signed-off-by: Jared Rossi <jrossi@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20241020012953.1380075-16-jrossi@linux.ibm.com> [thuth: Fix endianness problem when accessing the qipl structure] Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23s390x: Add individual loadparm assignment to CCW deviceJared Rossi6-52/+94
Add a loadparm property to the VirtioCcwDevice object so that different loadparms can be defined on a per-device basis for CCW boot devices. The machine/global loadparm is still supported. If both a global and per-device loadparm are defined, the per-device value will override the global value for that device, but any other devices that do not specify a per-device loadparm will still use the global loadparm. It is invalid to assign a loadparm to a non-boot device. Signed-off-by: Jared Rossi <jrossi@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20241020012953.1380075-15-jrossi@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23include/hw/s390x: Add include files for common IPL structsJared Rossi1-103/+1
Currently, structures defined in both hw/s390x/ipl.h and pc-bios/s390-ccw/iplb.h must be kept in sync, which is prone to error. Instead, create a new directory at include/hw/s390x/ipl/ to contain the definitions that must be shared. Signed-off-by: Jared Rossi <jrossi@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20241020012953.1380075-14-jrossi@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23hw/s390x: Remove the possibility to load the s390-netboot.img binaryThomas Huth3-71/+6
Since the netboot code has now been merged into the main s390-ccw.img binary, we don't need the separate s390-netboot.img anymore. Remove it and the code that was responsible for loading it. Message-Id: <20240621082422.136217-6-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-22hw/s390x/ipl: Provide more memory to the s390-ccw.img firmwareThomas Huth1-1/+9
We are going to link the SLOF libc into the s390-ccw.img, and this libc needs more memory for providing space for malloc() and friends. Thus bump the memory size that we reserve for the bios to 3 MiB instead of only 2 MiB. While we're at it, add a proper check that there is really enough memory assigned to the machine before blindly using it. Message-ID: <20240621082422.136217-3-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-07hw/s390x: Use explicit big-endian LD/ST APIPhilippe Mathieu-Daudé2-85/+85
The S390X architecture uses big endianness. Directly use the big-endian LD/ST API. Mechanical change using: $ end=be; \ for acc in uw w l q tul; do \ sed -i -e "s/ld${acc}_p(/ld${acc}_${end}_p(/" \ -e "s/st${acc}_p(/st${acc}_${end}_p(/" \ $(git grep -wlE '(ld|st)t?u?[wlq]_p' hw/s390x/); \ done Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20241004163042.85922-23-philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-09-24reset: Use ResetType for qemu_devices_reset() and MachineClass::reset()Juraj Marcin1-2/+2
Currently, both qemu_devices_reset() and MachineClass::reset() use ShutdownCause for the reason of the reset. However, the Resettable interface uses ResetState, so ShutdownCause needs to be translated to ResetType somewhere. Translating it qemu_devices_reset() makes adding new reset types harder, as they cannot always be matched to a single ShutdownCause here, and devices may need to check the ResetType to determine what to reset and if to reset at all. This patch moves this translation up in the call stack to qemu_system_reset() and updates all MachineClass children to use the ResetType instead. Message-ID: <20240904103722.946194-2-jmarcin@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Juraj Marcin <jmarcin@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2024-09-13hw: Use device_class_set_legacy_reset() instead of opencodingPeter Maydell4-5/+5
Use device_class_set_legacy_reset() instead of opencoding an assignment to DeviceClass::reset. This change was produced with: spatch --macro-file scripts/cocci-macro-file.h \ --sp-file scripts/coccinelle/device-reset.cocci \ --keep-comments --smpl-spacing --in-place --dir hw Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240830145812.1967042-8-peter.maydell@linaro.org
2024-09-13hw/s390/virtio-ccw: Convert to three-phase resetPeter Maydell2-6/+9
Convert the virtio-ccw code to three-phase reset. This allows us to remove a call to device_class_set_parent_reset(), replacing it with the three-phase equivalent resettable_class_set_parent_phases(). Removing all the device_class_set_parent_reset() uses will allow us to remove some of the glue code that interworks between three-phase and legacy reset. This is a simple conversion, with no behavioural changes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Acked-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240830145812.1967042-3-peter.maydell@linaro.org
2024-09-13hw/s390/ccw-device: Convert to three-phase resetPeter Maydell1-3/+4
Convert the TYPE_CCW_DEVICE to three-phase reset. This is a device class which is subclassed, so it needs to be three-phase before we can convert the subclass. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Thomas Huth <thuth@redhat.com> Message-id: 20240830145812.1967042-2-peter.maydell@linaro.org
2024-09-10qapi/machine: Rename CpuS390* to S390Cpu*, and drop 'prefix'Markus Armbruster1-3/+3
QAPI's 'prefix' feature can make the connection between enumeration type and its constants less than obvious. It's best used with restraint. CpuS390Entitlement has a 'prefix' to change the generated enumeration constants' prefix from CPU_S390_ENTITLEMENT to S390_CPU_ENTITLEMENT. Rename the type to S390CpuEntitlement, so that 'prefix' is not needed. Likewise change CpuS390Polarization to S390CpuPolarization, and CpuS390State to S390CpuState. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Acked-by: Thomas Huth <thuth@redhat.com> Message-ID: <20240904111836.3273842-10-armbru@redhat.com>
2024-09-05hw: add compat machines for 9.2Cornelia Huck1-1/+13
Add 9.2 machine types for arm/i440fx/m68k/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20240816161350.3706332-2-peter.maydell@linaro.org Message-id: 20240816103723.2325982-1-cohuck@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-03Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Richard Henderson1-4/+13
into staging virtio: features,fixes A bunch of improvements: - vhost dirty log is now only scanned once, not once per device - virtio and vhost now support VIRTIO_F_NOTIFICATION_DATA - cxl gained DCD emulation support - pvpanic gained shutdown support - beginning of patchset for Generic Port Affinity Structure - s3 support - friendlier error messages when boot fails on some illegal configs - for vhost-user, VHOST_USER_SET_LOG_BASE is now only sent once - part of vhost-user support for any POSIX system - not yet enabled due to qtest failures - sr-iov VF setup code has been reworked significantly - new tests, particularly for risc-v ACPI - bugfixes Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # -----BEGIN PGP SIGNATURE----- # # iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmaF068PHG1zdEByZWRo # YXQuY29tAAoJECgfDbjSjVRp+DMIAMC//mBXIZlPprfhb5cuZklxYi31Acgu5TUr # njqjCkN+mFhXXZuc3B67xmrQ066IEPtsbzCjSnzuU41YK4tjvO1g+LgYJBv41G16 # va2k8vFM5pdvRA+UC9li1CCIPxiEcszxOdzZemj3szWLVLLUmwsc5OZLWWeFA5m8 # vXrrT9miODUz3z8/Xn/TVpxnmD6glKYIRK/IJRzzC4Qqqwb5H3ji/BJV27cDUtdC # w6ns5RYIj5j4uAiG8wQNDggA1bMsTxFxThRDUwxlxaIwAcexrf1oRnxGRePA7PVG # BXrt5yodrZYR2sR6svmOOIF3wPMUDKdlAItTcEgYyxaVo5rAdpc= # =p9h4 # -----END PGP SIGNATURE----- # gpg: Signature made Wed 03 Jul 2024 03:41:51 PM PDT # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [undefined] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [undefined] # 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: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (85 commits) hw/pci: Replace -1 with UINT32_MAX for romsize pcie_sriov: Register VFs after migration pcie_sriov: Remove num_vfs from PCIESriovPF pcie_sriov: Release VFs failed to realize pcie_sriov: Reuse SR-IOV VF device instances pcie_sriov: Ensure VF function number does not overflow pcie_sriov: Do not manually unrealize hw/ppc/spapr_pci: Do not reject VFs created after a PF hw/ppc/spapr_pci: Do not create DT for disabled PCI device hw/pci: Rename has_power to enabled virtio-iommu: Clear IOMMUDevice when VFIO device is unplugged virtio: remove virtio_tswap16s() call in vring_packed_event_read() hw/cxl/events: Mark cxl-add-dynamic-capacity and cxl-release-dynamic-capcity unstable hw/cxl/events: Improve QMP interfaces and documentation for add/release dynamic capacity. tests/data/acpi/rebuild-expected-aml.sh: Add RISC-V pc-bios/meson.build: Add support for RISC-V in unpack_edk2_blobs meson.build: Add RISC-V to the edk2-target list tests/data/acpi/virt: Move ARM64 ACPI tables under aarch64/${machine} path tests/data/acpi: Move x86 ACPI tables under x86/${machine} path tests/qtest/bios-tables-test.c: Set "arch" for x86 tests ... Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-07-02Merge tag 'pull-request-2024-07-02' of https://gitlab.com/thuth/qemu into ↵Richard Henderson1-0/+8
staging * Fix interrupt controller migration on s390x with TCG and enable qtest * Fix memory leaks in qtests * Use a proper qom-tree parent for s390x virtio-net devices * Add hotplug avocado test for virtio-blk * Fix Travis jobs (need python3-tomli now) # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmaD1qsRHHRodXRoQHJl # ZGhhdC5jb20ACgkQLtnXdP5wLbWOtg//a+6nRcV8crCGzMaxhH32NxcjvV7TPiAI # FioqOsomKfKKTMIDlbjsgQiQWqGrN/mdnxSzasypxZrC3eoDYJCIUyQfR2iGe4t2 # JJ4gQhQGuXkSstGErj8yw83UnG1drG+XuZ/psSij4/R2ft6Me8miFSh3cCgIm541 # 0DtffV6rAXIEqA+bswKsPq+7bq6ZCxZjaWgKhzfP5RNnpjPvHYMDDPZt9a2Fk9xC # d3TILh/0djuVr8nZNUkQJBT5EU6dxVDb1JMqn4G6e6kWtiDBh/XwvMtC0KHVCJH1 # tHDz7n+FpwBfpo1cz0Y/Bn9pTW4K9KZ+GVlLOihfbh7Eaix0+RPzLKCigLVg1v8I # HaNFr70FxF5Xzmvie36arEKf0CwQCinxvfM9USBD0uP3tOzSZwX2XxM0+FBIjUf3 # fYIY8qV1hQZM5tXFxtU5LW4A64pVGwEHlEIcodxo8mY/DnZUdIvB5L5C4rxATnVr # t2eWc23sGdMZgKxUtlG0PIr80ImkYBWFOLztUmDPOff6igiyw2ZxaLQHyERPEc0O # 1CL4K4K5FKNtJgjSwJyU1NquGKk85vUSjiUW1JOvInUFjRECIQ7+R41p6FU+eTHO # l50cKaf2TCWqDOwMOjFYOHj6TWZGXnTmkSN60g0OLioy3UY+Kghd2Zq+aTK5ptyh # 1BhcvTin9Zg= # =lLG3 # -----END PGP SIGNATURE----- # gpg: Signature made Tue 02 Jul 2024 03:30:03 AM PDT # gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5 # gpg: issuer "thuth@redhat.com" # gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full] # gpg: aka "Thomas Huth <thuth@redhat.com>" [full] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] # gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full] * tag 'pull-request-2024-07-02' of https://gitlab.com/thuth/qemu: pc-bios/s390-ccw: Remove duplicated LDFLAGS .travis.yml: Install python3-tomli in all build jobs tests/avocado: add hotplug_blk test hw/s390x: Attach default virtio-net devices to the /machine/virtual-css-bridge docs: add precision about capstone for execlog plugin tests/qtest: Free GThread tests/qtest: Free paths tests/qtest: Free old machine variable name tests/qtest: Free unused QMP response tests/qtest: Use qtest_add_data_func_full() tests/qtest/migration-test: enable on s390x with TCG hw/intc/s390_flic: Fix interrupt controller migration on s390x with TCG Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-07-02hw/s390x: Attach default virtio-net devices to the /machine/virtual-css-bridgeThomas Huth1-0/+3
The initial virtio-net-ccw devices currently do not have a proper parent in the QOM tree, so they show up under /machine/unattached - which is somewhat ugly. Let's attach them to /machine/virtual-css-bridge/virtual-css instead. Message-ID: <20240701200108.154271-1-thuth@redhat.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-07-02hw/intc/s390_flic: Fix interrupt controller migration on s390x with TCGThomas Huth1-0/+5
Migration of a s390x guest with TCG was long known to be very unstable, so the tests in tests/qtest/migration-test.c are disabled if running with TCG instead of KVM. Nicholas Piggin did a great analysis of the problem: "The flic pending state is not migrated, so if the machine is migrated while an interrupt is pending, it can be lost. This shows up in qtest migration test, an extint is pending (due to console writes?) and the CPU waits via s390_cpu_set_psw and expects the interrupt to wake it. However when the flic pending state is lost, s390_cpu_has_int returns false, so s390_cpu_exec_interrupt falls through to halting again." Thus let's finally migrate the pending state, and to be on the safe side, also the other state variables of the QEMUS390FLICState structure. Message-ID: <20240619144421.261342-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-07-02hw: skip registration of outdated versioned machine typesDaniel P. Berrangé1-0/+1
This calls the MACHINE_VER_DELETION() macro in the machine type registration method, so that when a versioned machine type reaches the end of its life, it is no longer registered with QOM and thus cannot be used. The actual definition of the machine type should be deleted at this point, but experience shows that can easily be forgotten. By skipping registration the manual code deletion task can be done at any later date. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240620165742.1711389-12-berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-02hw: set deprecation info for all versioned machine typesDaniel P. Berrangé1-0/+1
This calls the MACHINE_VER_DEPRECATION() macro in the definition of all machine type classes which support versioning. This ensures that they will automatically get deprecation info set when they reach the appropriate point in their lifecycle. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240620165742.1711389-11-berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-02hw/s390x: convert 'ccw' machine definitions to use new macrosDaniel P. Berrangé1-43/+53
This changes the DEFINE_CCW_MACHINE macro to use the common helpers for constructing versioned symbol names and strings, bringing greater consistency across targets. The added benefit is that it avoids the need to repeat the version number twice in two different formats in the calls to DEFINE_CCW_MACHINE. A DEFINE_CCW_MACHINE_AS_LATEST helper is added so that it is not required to pass 'false' for every single historical machine type. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240620165742.1711389-4-berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-01virtio-ccw: Handle extra notification dataJonah Palmer1-4/+13
Add support to virtio-ccw devices for handling the extra data sent from the driver to the device when the VIRTIO_F_NOTIFICATION_DATA transport feature has been negotiated. The extra data that's passed to the virtio-ccw device when this feature is enabled varies depending on the device's virtqueue layout. That data passed to the virtio-ccw device is in the same format as the data passed to virtio-pci devices. Signed-off-by: Jonah Palmer <jonah.palmer@oracle.com> Message-Id: <20240315165557.26942-5-jonah.palmer@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-06-24target/s390x: Add a CONFIG switch to disable legacy CPUsThomas Huth1-0/+5
The oldest model that IBM still supports is the z13. Considering that each generation can "emulate" the previous two generations in hardware (via the "IBC" feature of the CPUs), this means that everything that is older than z114/196 is not an officially supported CPU model anymore. The Linux kernel still support the z10, so if we also take this into account, everything older than that can definitely be considered as a legacy CPU model. For downstream builds of QEMU, we would like to be able to disable these legacy CPUs in the build. Thus add a CONFIG switch that can be used to disable them (and old machine types that use them by default). Message-Id: <20240614125019.588928-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-06-24s390x/css: Make S390CCWDeviceClass::realize return boolCédric Le Goater1-3/+4
Since the realize() handler of S390CCWDeviceClass takes an 'Error **' argument, best practices suggest to return a bool. See the api/error.h Rules section. While at it, modify the call in vfio_ccw_realize(). Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20240522170107.289532-5-clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-06-24hw/s390x/ccw: Remove local Error variable from s390_ccw_realize()Cédric Le Goater1-8/+5
Use the 'Error **errp' argument of s390_ccw_realize() instead and remove the error_propagate() call. Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20240522170107.289532-4-clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-06-24s390x/css: Make CCWDeviceClass::realize return boolCédric Le Goater3-4/+4
Since the realize() handler of CCWDeviceClass takes an 'Error **' argument, best practices suggest to return a bool. See the api/error.h Rules section. While at it, modify the call in s390_ccw_realize(). Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20240522170107.289532-3-clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>