aboutsummaryrefslogtreecommitdiff
path: root/hw/s390x
AgeCommit message (Collapse)Author
2018-07-11error: Remove NULL checks on error_propagate() callsPhilippe Mathieu-Daudé
Patch created mechanically by rerunning: $ spatch --sp-file scripts/coccinelle/error_propagate_null.cocci \ --macro-file scripts/cocci-macro-file.h \ --dir . --in-place Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20180705155811.20366-3-f4bug@amsat.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-07-11s390x/storage attributes: fix CMMA_BLOCK_SIZE usageClaudio Imbrenda
The macro CMMA_BLOCK_SIZE was defined but not used, and a hardcoded value was instead used in the code. This patch fixes the value of CMMA_BLOCK_SIZE and uses it in the appropriate place in the code, and fixes another case of hardcoded value in the KVM backend, replacing it with the more appropriate constant KVM_S390_CMMA_SIZE_MAX. Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Message-Id: <1530787170-3101-1-git-send-email-imbrenda@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-07-02Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell
* IEC units series (Philippe) * Hyper-V PV TLB flush (Vitaly) * git archive detection (Daniel) * host serial passthrough fix (David) * NPT support for SVM emulation (Jan) * x86 "info mem" and "info tlb" fix (Doug) # gpg: Signature made Mon 02 Jul 2018 16:18:21 BST # gpg: using RSA key BFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (50 commits) tcg: simplify !CONFIG_TCG handling of tb_invalidate_* i386/monitor.c: make addresses canonical for "info mem" and "info tlb" target-i386: Add NPT support serial: Open non-block bsd-user: Use the IEC binary prefix definitions linux-user: Use the IEC binary prefix definitions tests/crypto: Use the IEC binary prefix definitions vl: Use the IEC binary prefix definitions monitor: Use the IEC binary prefix definitions cutils: Do not include "qemu/units.h" directly hw/rdma: Use the IEC binary prefix definitions hw/virtio: Use the IEC binary prefix definitions hw/vfio: Use the IEC binary prefix definitions hw/sd: Use the IEC binary prefix definitions hw/usb: Use the IEC binary prefix definitions hw/net: Use the IEC binary prefix definitions hw/i386: Use the IEC binary prefix definitions hw/ppc: Use the IEC binary prefix definitions hw/mips: Use the IEC binary prefix definitions hw/mips/r4k: Constify params_size ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-07-02hw/s390x: Use the IEC binary prefix definitionsPhilippe Mathieu-Daudé
It eases code review, unit is explicit. Patch generated using: $ git grep -E '(1024|2048|4096|8192|(<<|>>).?(10|20|30))' hw/ include/hw/ and modified manually. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20180625124238.25339-20-f4bug@amsat.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-07-02s390x/tcg: properly implement the TODDavid Hildenbrand
Right now, each CPU has its own TOD. Especially, the TOD will differ based on creation time of a CPU - e.g. when hotplugging a CPU the times will differ quite a lot, resulting in stall warnings in the guest. Let's use a single TOD by implementing our new TOD device. Prepare it for TOD-clock epoch extension. Most importantly, whenever we set the TOD, we have to update the CKC timer. Introduce "tcg_s390x.h" just like "kvm_s390x.h" for tcg specific function declarations that should not go into cpu.h. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20180627134410.4901-6-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-07-02s390x/tod: factor out TOD into separate deviceDavid Hildenbrand
Let's treat this like a separate device. TCG will have to store the actual state/time later on. Include cpu-qom.h in kvm_s390x.h (due to S390CPU) to compile tod-kvm.c. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20180627134410.4901-4-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-07-02s390x/cpumodel: default enable bpb and ppa15 for z196 and laterChristian Borntraeger
Most systems and host kernels provide the necessary building blocks for bpb and ppa15. We can reverse the logic and default enable those features, while still allowing to disable it via cpu model. So let us add bpb and ppa15 to z196 and later default CPU model for the qemu 3.0 machine. (like -cpu z13). Older machine types (e.g. s390-ccw-virtio-2.12) will retain the old value and not provide those bits in the default model. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20180626123830.18282-1-borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-07-02loader: Check access size when calling rom_ptr() to avoid crashesThomas Huth
The rom_ptr() function allows direct access to the ROM blobs that we load during startup. However, there are currently no checks for the size of the accesses, so it's currently possible to crash QEMU for example with: $ echo "Insane in the mainframe" > /tmp/test.txt $ s390x-softmmu/qemu-system-s390x -kernel /tmp/test.txt -append xyz Segmentation fault (core dumped) $ s390x-softmmu/qemu-system-s390x -kernel /tmp/test.txt -initrd /tmp/test.txt Segmentation fault (core dumped) $ echo -n HdrS > /tmp/hdr.txt $ sparc64-softmmu/qemu-system-sparc64 -kernel /tmp/hdr.txt -initrd /tmp/hdr.txt Segmentation fault (core dumped) We need a possibility to check the size of the ROM area that we want to access, thus let's add a size parameter to the rom_ptr() function to avoid these problems. Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1530005740-25254-1-git-send-email-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-07-02s390/ipl: fix ipl with -no-rebootChristian Borntraeger
kexec/kdump as well as the bootloader use a subcode of diagnose 308 that is supposed to reset the I/O subsystem but not comprise a full "reboot". With the latest refactoring this is now broken when -no-reboot is used or when libvirt acts on a reboot QMP event, for example a virt-install from iso images. We need to mark these "subsystem resets" as special. Fixes: a30fb811cbe9 (s390x: refactor reset/reipl handling) Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20180622102928.173420-1-borntraeger@de.ibm.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-06-18s390x/ipl: Try to detect Linux vs non Linux for initial IPL PSWChristian Borntraeger
Right now the IPL device always starts from address 0x10000 (the usual Linux entry point). To run other guests (e.g. test programs) it is useful to use the IPL PSW from address 0. We can use the Linux magic at 0x10008 to decide. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20180612125933.262679-1-borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-06-18vfio-ccw: remove orb.c64 (64 bit data addresses) checkHalil Pasic
The vfio-ccw module does the check too, and there is actually no technical obstacle for supporting fmt 1 idaws. Let us be ready for the beautiful day when fmt 1 idaws become supported by the vfio-ccw kernel module. QEMU does not have to do a thing for that, except not insisting on this check. Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Acked-by: Jason J. Herne <jjherne@linux.ibm.com> Tested-by: Jason J. Herne <jjherne@linux.ibm.com> Message-Id: <20180524175828.3143-3-pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-06-18vfio-ccw: add force unlimited prefetch propertyHalil Pasic
There is at least one guest (OS) such that although it does not rely on the guarantees provided by ORB 1 word 9 bit (aka unlimited prefetch, aka P bit) not being set, it fails to tell this to the machine. Usually this ain't a big deal, as the original purpose of the P bit is to allow for performance optimizations. vfio-ccw however can not provide the guarantees required if the bit is not set. It is not possible to implement support for the P bit not set without transitioning to lower level protocols for vfio-ccw. So let's give the user the opportunity to force setting the P bit, if the user knows this is safe. For self modifying channel programs forcing the P bit is not safe. If the P bit is forced for a self modifying channel program things are expected to break in strange ways. Let's also avoid warning multiple about P bit not set in the ORB in case P bit is not told to be forced, and designate the affected vfio-ccw device. Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Suggested-by: Dong Jia Shi <bjsdjshi@linux.ibm.com> Acked-by: Jason J. Herne <jjherne@linux.ibm.com> Tested-by: Jason J. Herne <jjherne@linux.ibm.com> Message-Id: <20180524175828.3143-2-pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-06-18virtio-ccw: clean up notifyHalil Pasic
Coverity recently started complaining about virtio_ccw_notify(). Turns out, there is a couple of things that can be cleaned up. Let's clean! Reported-by: Peter Maydell <peter.maydell@linaro.org> Fixes: CID 1390619 Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Message-Id: <20180516132757.68558-1-pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-06-15iommu: Add IOMMU index argument to translate methodPeter Maydell
Add an IOMMU index argument to the translate method of IOMMUs. Since all of our current IOMMU implementations support only a single IOMMU index, this has no effect on the behaviour. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20180604152941.20374-4-peter.maydell@linaro.org
2018-06-15iommu: Add IOMMU index argument to notifier APIsPeter Maydell
Add support for multiple IOMMU indexes to the IOMMU notifier APIs. When initializing a notifier with iommu_notifier_init(), the caller must pass the IOMMU index that it is interested in. When a change happens, the IOMMU implementation must pass memory_region_notify_iommu() the IOMMU index that has changed and that notifiers must be called for. IOMMUs which support only a single index don't need to change. Callers which only really support working with IOMMUs with a single index can use the result of passing MEMTXATTRS_UNSPECIFIED to memory_region_iommu_attrs_to_index(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20180604152941.20374-3-peter.maydell@linaro.org
2018-06-01Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell
* Linux header upgrade (Peter) * firmware.json definition (Laszlo) * IPMI migration fix (Corey) * QOM improvements (Alexey, Philippe, me) * Memory API cleanups (Jay, me, Tristan, Peter) * WHPX fixes and improvements (Lucian) * Chardev fixes (Marc-André) * IOMMU documentation improvements (Peter) * Coverity fixes (Peter, Philippe) * Include cleanup (Philippe) * -clock deprecation (Thomas) * Disable -sandbox unless CONFIG_SECCOMP (Yi Min Zhao) * Configurability improvements (me) # gpg: Signature made Fri 01 Jun 2018 17:42:13 BST # gpg: using RSA key BFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (56 commits) hw: make virtio devices configurable via default-configs/ hw: allow compiling out SCSI memory: Make operations using MemoryRegionIoeventfd struct pass by pointer. char: Remove unwanted crlf conversion qdev: Remove DeviceClass::init() and ::exit() qdev: Simplify the SysBusDeviceClass::init path hw/i2c: Use DeviceClass::realize instead of I2CSlaveClass::init hw/i2c/smbus: Use DeviceClass::realize instead of SMBusDeviceClass::init target/i386/kvm.c: Remove compatibility shim for KVM_HINTS_REALTIME Update Linux headers to 4.17-rc6 target/i386/kvm.c: Handle renaming of KVM_HINTS_DEDICATED scripts/update-linux-headers: Handle kernel license no longer being one file scripts/update-linux-headers: Handle __aligned_u64 virtio-gpu-3d: Define VIRTIO_GPU_CAPSET_VIRGL2 elsewhere gdbstub: Prevent fd leakage docs/interop: add "firmware.json" ipmi: Use proper struct reference for KCS vmstate vmstate: Add a VSTRUCT type tcg: remove softfloat from --disable-tcg builds qemu-options: Mark the non-functional -clock option as deprecated ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-06-01hw: Do not include "sysemu/blockdev.h" if it is not necessaryPhilippe Mathieu-Daudé
Remove those unneeded includes to speed up the compilation process a little bit. Code change produced with: $ git grep '#include "sysemu/blockdev.h"' | \ cut -d: -f-1 | \ xargs egrep -L "(BlockInterfaceType|DriveInfo|drive_get|blk_legacy_dinfo|blockdev_mark_auto_del)" | \ xargs sed -i.bak '/#include "sysemu\/blockdev.h"/d' Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20180528232719.4721-15-f4bug@amsat.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-01hw: Do not include "sysemu/block-backend.h" if it is not necessaryPhilippe Mathieu-Daudé
Remove those unneeded includes to speed up the compilation process a little bit. (Continue 7eceff5b5a1fa cleanup) Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20180528232719.4721-13-f4bug@amsat.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-05-31Make memory_region_access_valid() take a MemTxAttrs argumentPeter Maydell
As part of plumbing MemTxAttrs down to the IOMMU translate method, add MemTxAttrs as an argument to memory_region_access_valid(). Its callers either have an attrs value to hand, or don't care and can use MEMTXATTRS_UNSPECIFIED. The callsite in flatview_access_valid() is part of a recursive loop flatview_access_valid() -> memory_region_access_valid() -> subpage_accepts() -> flatview_access_valid(); we make it pass MEMTXATTRS_UNSPECIFIED for now, until the next several commits have plumbed an attrs parameter through the rest of the loop and we can add an attrs parameter to flatview_access_valid(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20180521140402.23318-8-peter.maydell@linaro.org
2018-05-29hw/s390x: Rename 2.13 machines to 3.0Peter Maydell
Rename the 2.13 machines to match the number we're going to use for the next release. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-id: 20180522104000.9044-4-peter.maydell@linaro.org
2018-05-14s390x: refactor reset/reipl handlingDavid Hildenbrand
Calling pause_all_vcpus()/resume_all_vcpus() from a VCPU thread might not be the best idea. As pause_all_vcpus() temporarily drops the qemu mutex, two parallel calls to pause_all_vcpus() can be active at a time, resulting in a deadlock. (either by two VCPUs or by the main thread and a VCPU) Let's handle it via the main loop instead, as suggested by Paolo. If we would have two parallel reset requests by two different VCPUs at the same time, the last one would win. We use the existing ipl device to handle it. The nice side effect is that we can get rid of reipl_requested. This change implies that all reset handling now goes via the common path, so "no-reboot" handling is now active for all kinds of reboots. Let's execute any CPU initialization code on the target CPU using run_on_cpu. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20180424101859.10239-1-david@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-05-14s390x/ccw: make sure all ccw devices are properly resetCornelia Huck
Thomas reported that the subchannel for a 3270 device that ended up in a broken state (status pending even though not enabled) did not get out of that state even after a reboot (which involves a subsytem reset). The reason for this is that the 3270 device did not define a reset handler. Let's fix this by introducing a base reset handler (set up for all ccw devices) that resets the subchannel and have virtio-ccw call its virtio-specific reset procedure in addition to that. CC: qemu-stable@nongnu.org Reported-by: Thomas Huth <thuth@redhat.com> Suggested-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-05-14virtio-ccw: common reset handlerCornelia Huck
All the different virtio ccw devices use the same reset handler, so let's move setting it into the base virtio ccw device class. CC: qemu-stable@nongnu.org Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-05-14s390x/css: disabled subchannels cannot be status pendingCornelia Huck
The 3270 code will try to post an attention interrupt when the 3270 emulator (e.g. x3270) attaches. If the guest has not yet enabled the subchannel for the 3270 device, we will present a spurious cc 1 (status pending) when it uses msch on it later on, e.g. when trying to enable the subchannel. To fix this, just don't do anything in css_conditional_io_interrupt() if the subchannel is not enabled. The 3270 code will work fine with that, and the other user of this function (virtio-ccw) never attempts to post an interrupt for a disabled device to begin with. CC: qemu-stable@nongnu.org Reported-by: Thomas Huth <thuth@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-05-10make sure that we aren't overwriting mc->get_hotplug_handler by accidentIgor Mammedov
Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 1525691524-32265-5-git-send-email-imammedo@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-05-02pc-bios/s390-ccw: fix loadparm initialization and int conversionCollin Walling
Rename the loadparm char array in main.c to loadparm_str and increased the size by one byte to account for a null termination when converting the loadparm string to an int via atoui. We also allow the boot menu to be enabled when loadparm is set to an empty string or a series of spaces. Signed-off-by: Collin Walling <walling@linux.ibm.com> Reported-by: Vasily Gorbik <gor@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2018-04-30hw/s390x: Allow to configure the consoles with the "-serial" parameterThomas Huth
The consoles ("sclpconsole" and "sclplmconsole") can only be configured with "-device" and "-chardev" so far. Other machines use the convenience option "-serial" to configure the default consoles, even for virtual consoles like spapr-vty on the pseries machine. So let's support this option on s390x, too. This way we can easily enable the serial console here again with "-nodefaults", for example: qemu-system-s390x -no-shutdown -nographic -nodefaults -serial mon:stdio ... which is way shorter than typing: qemu-system-s390x -no-shutdown -nographic -nodefaults \ -chardev stdio,id=c1,mux=on -device sclpconsole,chardev=c1 \ -mon chardev=c1 The -serial parameter can also be used if you only want to see the QEMU monitor on stdio without using -nodefaults, but not the console output. That's something that is pretty impossible with the current code today: qemu-system-s390x -no-shutdown -nographic -serial none While we're at it, this patch also maps the second -serial option to the "sclplmconsole", so that there is now an easy way to configure this second console on s390x, too, for example: qemu-system-s390x -no-shutdown -nographic -serial null -serial mon:stdio Additionally, the new code is also smaller than the old one and we have less s390x-specific code in vl.c :-) I've also checked that migration still works as expected by migrating a guest with console output back and forth between a qemu-system-s390x that has this patch and an instance without this patch. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1524754794-28005-1-git-send-email-thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-04-30s390x/kvm: cleanup calls to cpu_synchronize_state()David Hildenbrand
We have a call to cpu_synchronize_state() on every kvm_arch_handle_exit(). Let's remove the ones that are no longer needed. Remaining places (for s390x) are in - target/s390x/sigp.c, on the target CPU - target/s390x/cpu.c:s390_cpu_get_crash_info() While at it, use kvm_cpu_synchronize_state() instead of cpu_synchronize_state() in KVM code. (suggested by Thomas Huth) Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20180412093521.2469-1-david@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-04-30s390x/sclp: extend SCLP event masks to 64 bitsClaudio Imbrenda
Extend the SCLP event masks to 64 bits. Notice that using any of the new bits results in a state that cannot be migrated to an older version. Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Message-Id: <1520507069-22179-1-git-send-email-imbrenda@linux.vnet.ibm.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-04-30s390x: introduce 2.13 compat machineCornelia Huck
Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-04-09s390: Ensure IPL from SCSI works as expectedViktor Mihajlovski
Operating systems may request an IPL from a virtio-scsi device by specifying an IPL parameter type of CCW. In this case QEMU won't set up the IPLB correctly. The BIOS will still detect it's a SCSI device to boot from, but it will now have to search for the first LUN and attempt to boot from there. However this may not be the original boot LUN if there's more than one SCSI disk attached to the HBA. With this change QEMU will detect that the request is for a SCSI device and will rebuild the initial IPL parameter info if it's the SCSI device used for the first boot. In consequence the BIOS can use the boot LUN from the IPL information block. In case a different SCSI device has been set, the BIOS will find and use the first available LUN. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Message-Id: <1522940844-12336-3-git-send-email-mihajlov@linux.vnet.ibm.com> Reviewed-by: Farhan Ali <alifm@linux.vnet.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-04-09s390: Refactor IPL parameter block generationViktor Mihajlovski
Splitting out the the CCW device extraction allows reuse. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Message-Id: <1522940844-12336-2-git-send-email-mihajlov@linux.vnet.ibm.com> Reviewed-by: Farhan Ali <alifm@linux.vnet.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-04-03hw/s390x: fix memory leak in s390_init_ipl_dev()Greg Kurz
The string returned by object_property_get_str() is dynamically allocated. Fixes: 3c4e9baacf4d9 Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <152231460685.69730.14860451936216690693.stgit@bahia.lan> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-23s390x/pci: forbid multifunction pci deviceYi Min Zhao
Currently we don't support pci multifunction. If a pci with multifucntion is plugged, the guest will spin forever. This patch fixes this. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2018-03-13migration: introduce postcopy-only pendingVladimir Sementsov-Ogievskiy
There would be savevm states (dirty-bitmap) which can migrate only in postcopy stage. The corresponding pending is introduced here. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-id: 20180313180320.339796-6-vsementsov@virtuozzo.com
2018-03-08s390x/virtio: Convert virtio-ccw from *_exit to *_unrealizeNia Alarie
Signed-off-by: Nia Alarie <nia.alarie@gmail.com> Message-Id: <20180307162958.11232-1-nia.alarie@gmail.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08s390x/sclp: clean up sclp masksClaudio Imbrenda
Introduce an sccb_mask_t to be used for SCLP event masks instead of just unsigned int or uint32_t. This will allow later to extend the mask with more ease. Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Message-Id: <1519407778-23095-3-git-send-email-imbrenda@linux.vnet.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08s390x/sclp: proper support of larger send and receive masksClaudio Imbrenda
Until 67915de9f0383ccf4a ("s390x/event-facility: variable-length event masks") we only supported sclp event masks with a size of exactly 4 bytes, even though the architecture allows the guests to set up sclp event masks from 1 to 1021 bytes in length. After that patch, the behaviour was almost compliant, but some issues were still remaining, in particular regarding the handling of selective reads and migration. When setting the sclp event mask, a mask size is also specified. Until now we only considered the size in order to decide which bits to save in the internal state. On the other hand, when a guest performs a selective read, it sends a mask, but it does not specify a size; the implied size is the size of the last mask that has been set. Specifying bits in the mask of selective read that are not available in the internal mask should return an error, and bits past the end of the mask should obviously be ignored. This can only be achieved by keeping track of the lenght of the mask. The mask length is thus now part of the internal state that needs to be migrated. This patch fixes the handling of selective reads, whose size will now match the length of the event mask, as per architecture. While the default behaviour is to be compliant with the architecture, when using older machine models the old broken behaviour is selected (allowing only masks of size exactly 4), in order to be able to migrate toward older versions. Fixes: 67915de9f0383ccf4a ("s390x/event-facility: variable-length event masks") Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Message-Id: <1519407778-23095-2-git-send-email-imbrenda@linux.vnet.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08s390x/sclpconsole: Remove dead code - remove exit handlersNia Alarie
The other event handlers (quiesce and cpu) do not define these handlers, and this one does nothing, so it can be removed. Signed-off-by: Nia Alarie <nia.alarie@gmail.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20180306100721.19419-1-nia.alarie@gmail.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08numa: we don't implement NUMA for s390xDavid Hildenbrand
Right now it is possible to crash QEMU for s390x by providing e.g. -numa node,nodeid=0,cpus=0-1 Problem is, that numa.c uses mc->cpu_index_to_instance_props as an indicator whether NUMA is supported by a machine type. We don't implement NUMA for s390x ("topology") yet. However we need mc->cpu_index_to_instance_props for query-cpus. So let's fix this case by also checking for mc->get_default_cpu_node_id, which will be needed by machine_set_cpu_numa_node(). qemu-system-s390x: -numa node,nodeid=0,cpus=0-1: NUMA is not supported by this machine-type While at it, make s390_cpu_index_to_props() look like on other architectures. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20180227110255.20999-1-david@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08hw/s390x: Add the possibility to specify the netboot image on the command lineThomas Huth
The file name of the netboot binary is currently hard-coded to "s390-netboot.img", without a possibility for the user to select an alternative firmware image here. That's unfortunate, especially since the basics are already there: The filename is a property of the s390-ipl device. So we just have to add a check whether the user already provided the property and only set the default if the string is still empty. Now it is possible to select a different firmware image with "-global s390-ipl.netboot_fw=/path/to/s390-netboot.img". Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1519731154-3127-1-git-send-email-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08s390/ipl: only print boot menu error if -boot menu=on was specifiedCollin L. Walling
It is possible that certain QEMU configurations may not create an IPLB (such as when -kernel is provided). In this case, a misleading error message will be printed stating that the "boot menu is not supported for this device type". To amend this, only print this message iff boot menu=on was provided on the commandline. Otherwise, return silently. While we're at it, remove trailing periods from error messages. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Message-Id: <1519760121-24594-1-git-send-email-walling@linux.vnet.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08hw/s390x/ipl: Bail out if the network bootloader can not be foundThomas Huth
If QEMU fails to load 's390-netboot.img', the guest firmware currently loops forever and just floods the console with "Network boot device detected" messages. The code in ipl.c apparently already tried to stop the VM with vm_stop() in this case, but this is in vain since the run state is later reset due to a call to vm_start() from vl.c again. To avoid the ugly firmware loop, let's simply exit QEMU directly instead since it just does not make sense to continue if the required firmware image can not be loaded. While we're at it, also add the file name of the netboot binary to the error message, so that the user has a better hint about what is missing. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1519725913-24852-1-git-send-email-thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Farhan Ali <alifm@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-06use g_path_get_basename instead of basenameJulia Suvorova
basename(3) and dirname(3) modify their argument and may return pointers to statically allocated memory which may be overwritten by subsequent calls. g_path_get_basename and g_path_get_dirname have no such issues, and therefore more preferable. Signed-off-by: Julia Suvorova <jusual@mail.ru> Message-Id: <1519888086-4207-1-git-send-email-jusual@mail.ru> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-02qapi: Empty out qapi-schema.jsonMarkus Armbruster
The previous commit improved compile time by including less of the generated QAPI headers. This is impossible for stuff defined directly in qapi-schema.json, because that ends up in headers that that pull in everything. Move everything but include directives from qapi-schema.json to new sub-module qapi/misc.json, then include just the "misc" shard where possible. It's possible everywhere, except: * monitor.c needs qmp-command.h to get qmp_init_marshal() * monitor.c, ui/vnc.c and the generated qapi-event-FOO.c need qapi-event.h to get enum QAPIEvent Perhaps we'll get rid of those some other day. Adding a type to qapi/migration.json now recompiles some 120 instead of 2300 out of 5100 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180211093607.27351-25-armbru@redhat.com> [eblake: rebase to master] Signed-off-by: Eric Blake <eblake@redhat.com>
2018-02-27Merge tag 'tags/s390-ccw-bios-2018-02-26' into s390-nextCornelia Huck
Boot menu patches by Collin L. Walling # gpg: Signature made Mon 26 Feb 2018 11:24:21 AM CET # gpg: using RSA key 2ED9D774FE702DB5 # gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full] # gpg: aka "Thomas Huth <thuth@redhat.com>" [undefined] # gpg: aka "Thomas Huth <huth@tuxfamily.org>" [undefined] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] * tag 'tags/s390-ccw-bios-2018-02-26': pc-bios/s390: Rebuild the s390x firmware images with the boot menu changes s390-ccw: interactive boot menu for scsi s390-ccw: use zipl values when no boot menu options are present s390-ccw: set cp_receive mask only when needed and consume pending service irqs s390-ccw: read user input for boot index via the SCLP console s390-ccw: print zipl boot menu s390-ccw: read stage2 boot loader data to find menu s390-ccw: set up interactive boot menu parameters s390-ccw: parse and set boot menu options s390-ccw: move auxiliary IPL data to separate location s390-ccw: update libc s390-ccw: refactor IPL structs s390-ccw: refactor eckd_block_num to use CHS s390-ccw: refactor boot map table code
2018-02-26s390x/sclp: remove memory hotplug supportDavid Hildenbrand
From an architecture point of view, nothing can be mapped into the address space on s390x. All there is is memory. Therefore there is also not really an interface to communicate such information to the guest. All we can do is specify the maximum ram address and guests can probe in that range if memory is available and usable (TPROT). Also memory hotplug is strange. The guest can decide at some point in time to add / remove memory in some range. While the hypervisor can deny to online an increment, all increments have to be predefined and there is no way of telling the guest about a newly "hotplugged" increment. So if we specify right now e.g. -m 2G,slots=2,maxmem=20G An ordinary fedora guest will happily online (hotplug) all memory, resulting in a guest consuming 20G. So it really behaves rather like -m 22G There is no way to hotplug memory from the outside like on other architectures. This is of course bad for upper management layers. As the guest can create/delete memory regions while it is running, of course migration support is not available and tricky to implement. With virtualization, it is different. We might want to map something into guest address space (e.g. fake DAX devices) and not detect it automatically as memory. So we really want to use the maxmem and slots parameter just like on all other architectures. Such devices will have to expose the applicable memory range themselves. To finally be able to provide memory hotplug to guests, we will need a new paravirtualized interface to do that (e.g. something into the direction of virtio-mem). This implies, that maxmem cannot be used for s390x memory hotplug anymore and has to go. This simplifies the code quite a bit. As migration support is not working, this change cannot really break migration as guests without slots and maxmem don't see the SCLP features. Also, the ram size calculation does not change. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20180219174231.10874-1-david@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com> [CH: tweaked patch description, as discussed on list] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-26qmp: expose s390-specific CPU infoViktor Mihajlovski
Presently s390x is the only architecture not exposing specific CPU information via QMP query-cpus. Upstream discussion has shown that it could make sense to report the architecture specific CPU state, e.g. to detect that a CPU has been stopped. With this change the output of query-cpus will look like this on s390: [ {"arch": "s390", "current": true, "props": {"core-id": 0}, "cpu-state": "operating", "CPU": 0, "qom_path": "/machine/unattached/device[0]", "halted": false, "thread_id": 63115}, {"arch": "s390", "current": false, "props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1, "qom_path": "/machine/unattached/device[1]", "halted": true, "thread_id": 63116} ] This change doesn't add the s390-specific data to HMP 'info cpus'. A follow-on patch will remove all architecture specific information from there. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <1518797321-28356-2-git-send-email-mihajlov@linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-26s390/stattrib: Make SaveVMHandlers data staticDr. David Alan Gilbert
There's no need for this to be dynamic, make it static. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20180212154903.8859-1-dgilbert@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-26s390-ccw: interactive boot menu for scsiCollin L. Walling
Interactive boot menu for scsi. This follows a similar procedure as the interactive menu for eckd dasd. An example follows: s390x Enumerated Boot Menu. 3 entries detected. Select from index 0 to 2. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> [thuth: Added additional "break;" statement to avoid analyzer warnings] Signed-off-by: Thomas Huth <thuth@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-01-24 15:09:52 +0000