aboutsummaryrefslogtreecommitdiff
path: root/include/hw/s390x
AgeCommit message (Collapse)Author
2023-11-08Merge tag 'pull-request-2023-11-07' of https://gitlab.com/thuth/qemu into ↵Stefan Hajnoczi
staging * Fix s390x CPU reconfiguration information in the SCLP facility map * Fix condition code problem in the CLC and LAALG instruction * Fix ordering of the new s390x topology list entries * Add some more files to the MAINTAINERS file * Allow newer versions of Tesseract in the m68k nextcube test # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmVKgksRHHRodXRoQHJl # ZGhhdC5jb20ACgkQLtnXdP5wLbWIHg//TM3JOpsMEqHKlUKqOJH02mFQrK6H7LG0 # BC56FG7T+/mpYs1NTG92t8nCK03C2ZCweQWD7ZulRJAjPhZv+TF5bJEForivU7+k # PKEshz9xKCWn2YGyNnf2LA06J1JkF215+KlReOoxwSgj1cPlHfBLQ0DtxmpJJZ1G # h5p4d26BbSlwR58HrFWTlhgJMPenl59BETUGIK1FklBxunmZeeijddfniAhOT44y # i0u9/H9KCg3tkwBROUy+42QV+ef32kz/yvi5RmYQI5W7PixO4sxH6MYduOjshsu9 # wK70f8EOwiZV6lFxqmbV7vxFeNnp5IuaVU7PMBoAkwZqLw99mSFy1+1BabCuL5b+ # 3iUTiD4UW48MYwE2Ua6Lit4kpfjhwcp/UYz6pIk6TCBQX6LfzO+nj+rod0GdIpyZ # 4Lwm7jBtpTlYkGrsMvpA/qcidOtqPA1lmBTNlY1hFodQF6KWtyObn0w5AM80xeeU # /mGxQDz97Bpz7LKZvhu+k38jaWvnJFnl3jF1zet88CYL9YL+YI/k1KjhFafCXb0V # 38Xpt5JTWxyLSh2B3gx0OpokX5bftvW9GlLix0HqL7c23uYwR2Bq+Rd6I8SAlk4C # uJq6gqP8IFBFHfgbmyqf/fyd/eHxm7J1voIdy9PZyxZ1JYT9A7yu56qV6SJYwCpr # aARwui/Dm4o= # =y+cC # -----END PGP SIGNATURE----- # gpg: Signature made Wed 08 Nov 2023 02:30:35 HKT # 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 <huth@tuxfamily.org>" [full] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] # Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5 * tag 'pull-request-2023-11-07' of https://gitlab.com/thuth/qemu: target/s390x/cpu topology: Fix ordering and creation of TLEs tests/tcg/s390x: Test ADD LOGICAL WITH CARRY tests/tcg/s390x: Test LAALG with negative cc_src target/s390x: Fix LAALG not updating cc_src tests/tcg/s390x: Test CLC with inaccessible second operand target/s390x: Fix CLC corrupting cc_src target/s390x/cpu_models: Use 'first_cpu' in s390_get_feat_block() s390/sclp: fix SCLP facility map tests/avocado: Allow newer versions of tesseract in the nextcube test MAINTAINERS: Add artist.c to the hppa machine section MAINTAINERS: Add the virtio-gpu documentation to the corresponding section Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-11-07s390/sclp: fix SCLP facility mapHeiko Carstens
Qemu's SCLP implementation incorrectly reports that it supports CPU reconfiguration. If a guest issues a CPU reconfiguration request it is rejected as invalid command. Fix the SCLP_HAS_CPU_INFO mask, and remove the unused SCLP_CMDW_CONFIGURE_CPU and SCLP_CMDW_DECONFIGURE_CPU defines. Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Message-ID: <20231024100703.929679-1-hca@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-11-07hw/s390x/sclp: Have sclp_service_call[_protected]() take S390CPU*Philippe Mathieu-Daudé
"hw/s390x/sclp.h" is a header used by target-agnostic objects (such hw/char/sclpconsole[-lm].c), thus can not use target-specific types, such CPUS390XState. Have sclp_service_call[_protected]() take a S390CPU pointer, which is target-agnostic. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20231106114500.5269-3-philmd@linaro.org>
2023-11-07hw/s390x/css: Have css_do_sic() take S390CPU instead of CPUS390XStatePhilippe Mathieu-Daudé
"hw/s390x/css.h" is a header used by target-agnostic objects (such hw/s390x/virtio-ccw-gpu.c), thus can not use target-specific types, such CPUS390XState. Have css_do_sic() take S390CPU a pointer, which is target-agnostic. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20231106114500.5269-2-philmd@linaro.org>
2023-10-20s390x/cpu topology: interception of PTF instructionPierre Morel
When the host supports the CPU topology facility, the PTF instruction with function code 2 is interpreted by the SIE, provided that the userland hypervisor activates the interpretation by using the KVM_CAP_S390_CPU_TOPOLOGY KVM extension. The PTF instructions with function code 0 and 1 are intercepted and must be emulated by the userland hypervisor. During RESET all CPU of the configuration are placed in horizontal polarity. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Message-ID: <20231016183925.2384704-8-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-10-20s390x/cpu topology: resetting the Topology-Change-ReportPierre Morel
During a subsystem reset the Topology-Change-Report is cleared by the machine. Let's ask KVM to clear the Modified Topology Change Report (MTCR) bit of the SCA in the case of a subsystem reset. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Message-ID: <20231016183925.2384704-7-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-10-20s390x/sclp: reporting the maximum nested topology entriesPierre Morel
The maximum nested topology entries is used by the guest to know how many nested topology are available on the machine. Let change the MNEST value from 2 to 4 in the SCLP READ INFO structure now that we support books and drawers. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20231016183925.2384704-6-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-10-20target/s390x/cpu topology: handle STSI(15) and build the SYSIBPierre Morel
On interception of STSI(15.1.x) the System Information Block (SYSIB) is built from the list of pre-ordered topology entries. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Message-ID: <20231016183925.2384704-5-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-10-20s390x/cpu topology: add topology entries on CPU hotplugPierre Morel
The topology information are attributes of the CPU and are specified during the CPU device creation. On hot plug we: - calculate the default values for the topology for drawers, books and sockets in the case they are not specified. - verify the CPU attributes - check that we have still room on the desired socket The possibility to insert a CPU in a mask is dependent on the number of cores allowed in a socket, a book or a drawer, the checking is done during the hot plug of the CPU to have an immediate answer. If the complete topology is not specified, the core is added in the physical topology based on its core ID and it gets defaults values for the modifier attributes. This way, starting QEMU without specifying the topology can still get some advantage of the CPU topology. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Message-ID: <20231016183925.2384704-4-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-10-18vfio/ccw: Remove redundant definition of TYPE_VFIO_CCWZhenzhong Duan
No functional changes. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-07-25s390x: spelling fixesMichael Tokarev
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Thomas Huth <thuth@redhat.com>
2023-07-10hw/s390x: Move KVM specific PV from hw/ to target/s390x/kvm/Philippe Mathieu-Daudé
Protected Virtualization (PV) is not a real hardware device: it is a feature of the firmware on s390x that is exposed to userspace via the KVM interface. Move the pv.c/pv.h files to target/s390x/kvm/ to make this clearer. Suggested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230624200644.23931-1-philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-05-16s390x/pv: Fix spurious warning with asynchronous teardownClaudio Imbrenda
Kernel commit 292a7d6fca33 ("KVM: s390: pv: fix asynchronous teardown for small VMs") causes the KVM_PV_ASYNC_CLEANUP_PREPARE ioctl to fail if the VM is not larger than 2GiB. QEMU would attempt it and fail, print an error message, and then proceed with a normal teardown. Avoid attempting to use asynchronous teardown altogether when the VM is not larger than 2 GiB. This will avoid triggering the error message and also avoid pointless overhead; normal teardown is fast enough for small VMs. Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> Fixes: c3a073c610 ("s390x/pv: Add support for asynchronous teardown for reboot") Link: https://lore.kernel.org/all/20230421085036.52511-2-imbrenda@linux.ibm.com/ Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-Id: <20230510105531.30623-2-imbrenda@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> [thuth: Fix inline function parameter in pv.h] Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-02-27s390x/pv: Add support for asynchronous teardown for rebootClaudio Imbrenda
This patch adds support for the asynchronous teardown for reboot for protected VMs. When attempting to tear down a protected VM, try to use the new asynchronous interface first. If that fails, fall back to the classic synchronous one. The asynchronous interface involves invoking the new KVM_PV_ASYNC_DISABLE_PREPARE command for the KVM_S390_PV_COMMAND ioctl. This will prepare the current protected VM for asynchronous teardown. Once the protected VM is prepared for teardown, execution can continue immediately. Once the protected VM has been prepared, a new thread is started to actually perform the teardown. The new thread uses the new KVM_PV_ASYNC_DISABLE command for the KVM_S390_PV_COMMAND ioctl. The previously prepared protected VM is torn down in the new thread. Once KVM_PV_ASYNC_DISABLE is invoked, it is possible to use KVM_PV_ASYNC_DISABLE_PREPARE again. If a protected VM has already been prepared and its cleanup has not started, it will not be possible to prepare a new VM. In that case the classic synchronous teardown has to be performed. The synchronous teardown will now also clean up any prepared VMs whose asynchronous teardown has not been initiated yet. This considerably speeds up the reboot of a protected VM; for large VMs especially, it could take a long time to perform a reboot with the traditional synchronous teardown, while with this patch it is almost immediate. Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230214163035.44104-3-imbrenda@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-12-15s390x/pci: reset ISM passthrough devices on shutdown and system resetMatthew Rosato
ISM device firmware stores unique state information that can can cause a wholesale unmap of the associated IOMMU (e.g. when we get a termination signal for QEMU) to trigger firmware errors because firmware believes we are attempting to invalidate entries that are still in-use by the guest OS (when in fact that guest is in the process of being terminated or rebooted). To alleviate this, register both a shutdown notifier (for unexpected termination cases e.g. virsh destroy) as well as a reset callback (for cases like guest OS reboot). For each of these scenarios, trigger PCI device reset; this is enough to indicate to firmware that the IOMMU is no longer in-use by the guest OS, making it safe to invalidate any associated IOMMU entries. Fixes: 15d0e7942d3b ("s390x/pci: don't fence interpreted devices without MSI-X") Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-Id: <20221209195700.263824-1-mjrosato@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> [thuth: Adjusted the hunk in s390-pci-vfio.c due to different context] Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-12-15s390x/pci: shrink DMA aperture to be bound by vfio DMA limitMatthew Rosato
Currently, s390x-pci performs accounting against the vfio DMA limit and triggers the guest to clean up mappings when the limit is reached. Let's go a step further and also limit the size of the supported DMA aperture reported to the guest based upon the initial vfio DMA limit reported for the container (if less than than the size reported by the firmware/host zPCI layer). This avoids processing sections of the guest DMA table during global refresh that, for common use cases, will never be used anway, and makes exhausting the vfio DMA limit due to mismatch between guest aperture size and host limit far less likely and more indicitive of an error. Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-Id: <20221028194758.204007-4-mjrosato@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-11-08Revert "s390x/s390-virtio-ccw: add zpcii-disable machine property"Cédric Le Goater
This reverts commit 59d1ce44396e3ad2330dc3261ff3da7ad3a16184. The "zpcii-disable" machine property is redundant with the "interpret" zPCI device property. Remove it for clarification. Signed-off-by: Cédric Le Goater <clg@redhat.com> Message-Id: <20221107161349.1032730-2-clg@kaod.org> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-11-06s390x/cpu topology: add max_threads machine class attributePierre Morel
The S390 CPU topology accepts the smp.threads argument while in reality it does not effectively allow multthreading. Let's keep this behavior for machines older than 7.2 and refuse to use threads in newer machines until multithreading is really exposed to the guest by the machine. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Message-Id: <20221103170150.20789-3-pmorel@linux.ibm.com> [thuth: Small fixes to the commit description] Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-10-26s390x: Add KVM PV dump interfaceJanosch Frank
Let's add a few bits of code which hide the new KVM PV dump API from us via new functions. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Janis Schoetterl-Glausch <scgl@linux.ibm.com> Reviewed-by: Steffen Eiden <seiden@linux.ibm.com> [ Marc-André: fix up for compilation issue ] Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20221017083822.43118-10-frankja@linux.ibm.com>
2022-10-26s390x: Introduce PV query interfaceJanosch Frank
Introduce an interface over which we can get information about UV data. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Steffen Eiden <seiden@linux.ibm.com> Reviewed-by: Janis Schoetterl-Glausch <scgl@linux.ibm.com> Acked-by: Thomas Huth <thuth@redhat.com> Message-Id: <20221017083822.43118-8-frankja@linux.ibm.com>
2022-09-26s390x/s390-virtio-ccw: add zpcii-disable machine propertyMatthew Rosato
The zpcii-disable machine property can be used to force-disable the use of zPCI interpretation facilities for a VM. By default, this setting will be off for machine 7.2 and newer. Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-Id: <20220902172737.170349-9-mjrosato@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> [thuth: Fix contextual conflict in ccw_machine_7_1_instance_options()] Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-09-26s390x/pci: let intercept devices have separate PCI groupsMatthew Rosato
Let's use the reserved pool of simulated PCI groups to allow intercept devices to have separate groups from interpreted devices as some group values may be different. If we run out of simulated PCI groups, subsequent intercept devices just get the default group. Furthermore, if we encounter any PCI groups from hostdevs that are marked as simulated, let's just assign them to the default group to avoid conflicts between host simulated groups and our own simulated groups. Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Message-Id: <20220902172737.170349-7-mjrosato@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-09-26s390x/pci: enable adapter event notification for interpreted devicesMatthew Rosato
Use the associated kvm ioctl operation to enable adapter event notification and forwarding for devices when requested. This feature will be set up with or without firmware assist based upon the 'forwarding_assist' setting. Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-Id: <20220902172737.170349-6-mjrosato@linux.ibm.com> [thuth: Rename "forwarding_assist" property to "forwarding-assist"] Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-09-26s390x/pci: enable for load/store interpretationMatthew Rosato
If the ZPCI_OP ioctl reports that is is available and usable, then the underlying KVM host will enable load/store intepretation for any guest device without a SHM bit in the guest function handle. For a device that will be using interpretation support, ensure the guest function handle matches the host function handle; this value is re-checked every time the guest issues a SET PCI FN to enable the guest device as it is the only opportunity to reflect function handle changes. By default, unless interpret=off is specified, interpretation support will always be assumed and exploited if the necessary ioctl and features are available on the host kernel. When these are unavailable, we will silently revert to the interception model; this allows existing guest configurations to work unmodified on hosts with and without zPCI interpretation support, allowing QEMU to choose the best support model available. Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Thomas Huth <thuth@redhat.com> Message-Id: <20220902172737.170349-4-mjrosato@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-09-26s390x/pci: add routine to get host function handle from CLP infoMatthew Rosato
In order to interface with the underlying host zPCI device, we need to know its function handle. Add a routine to grab this from the vfio CLP capabilities chain. Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Message-Id: <20220902172737.170349-3-mjrosato@linux.ibm.com> [thuth: Replace free(info) with g_free(info)] Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-05-11Clean up ill-advised or unusual header guardsMarkus Armbruster
Leading underscores are ill-advised because such identifiers are reserved. Trailing underscores are merely ugly. Strip both. Our header guards commonly end in _H. Normalize the exceptions. Macros should be ALL_CAPS. Normalize the exception. Done with scripts/clean-header-guards.pl. include/hw/xen/interface/ and tools/virtiofsd/ left alone, because these were imported from Xen and libfuse respectively. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20220506134911.2856099-3-armbru@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2022-01-17s390x/css: fix PMCW invalid maskNico Boehr
Previously, we required bits 5, 6 and 7 to be zero (0x07 == 0b111). But, as per the principles of operation, bit 5 is ignored in MSCH and bits 0, 1, 6 and 7 need to be zero. As both PMCW_FLAGS_MASK_INVALID and ioinst_schib_valid() are only used by ioinst_handle_msch(), adjust the mask accordingly. Fixes: db1c8f53bfb1 ("s390: Channel I/O basic definitions.") Signed-off-by: Nico Boehr <nrb@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20211216131657.1057978-1-nrb@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-12-17s390x/pci: add supported DT information to clp responseMatthew Rosato
The DTSM is a mask that specifies which I/O Address Translation designation types are supported. Today QEMU only supports DT=1. Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Message-Id: <20211203142706.427279-5-mjrosato@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-12-17s390x/pci: use a reserved ID for the default PCI groupMatthew Rosato
The current default PCI group being used can technically collide with a real group ID passed from a hostdev. Let's instead use a group ID that comes from a special pool (0xF0-0xFF) that is architected to be reserved for simulated devices. Fixes: 28dc86a072 ("s390x/pci: use a PCI Group structure") Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Message-Id: <20211203142706.427279-2-mjrosato@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-06s390x: Replace PAGE_SIZE, PAGE_SHIFT and PAGE_MASKThomas Huth
The PAGE_SIZE macro is causing trouble on Alpine Linux since it clashes with a macro from a system header there. We already have the TARGET_PAGE_SIZE, TARGET_PAGE_MASK and TARGET_PAGE_BITS macros in QEMU anyway, so let's simply replace the PAGE_SIZE, PAGE_MASK and PAGE_SHIFT macro with their TARGET_* counterparts. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/572 Message-Id: <20210901125800.611183-1-thuth@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-06hw/s390x/s390-skeys: lazy storage key enablement under TCGDavid Hildenbrand
Let's enable storage keys lazily under TCG, just as we do under KVM. Only fairly old Linux versions actually make use of storage keys, so it can be kind of wasteful to allocate quite some memory and track changes and references if nobody cares. We have to make sure to flush the TLB when enabling storage keys after the VM was already running: otherwise it might happen that we don't catch references or modifications afterwards. Add proper documentation to all callbacks. The kvm-unit-tests skey tests keeps on working with this change. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210903155514.44772-14-david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-06hw/s390x/s390-skeys: rename skeys_enabled to skeys_are_enabledDavid Hildenbrand
... and make it return a bool instead. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210903155514.44772-13-david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-06css: fix actl handling for unit exceptionsCornelia Huck
When a subchannel becomes pending with unit exception, start pending (and for that matter, halt or clear pending) are not removed in the actl. Device active and subchannel active, however, are (due to the subchannel becoming status pending with primary respectively secondary status). The other conditions in the actl are only cleared when the guest executes tsch on the subchannel. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Tested-by: Jared Rossi <jrossi@linux.ibm.com> Message-Id: <20210705163952.736020-3-cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-07-07target/s390x: start moving TCG-only code to tcg/Cho, Yu-Chen
move everything related to translate, as well as HELPER code in tcg/ mmu_helper.c stays put for now, as it contains both TCG and KVM code. After the reshuffling, update MAINTAINERS accordingly. Make use of the new directory: target/s390x/tcg/ Signed-off-by: Claudio Fontana <cfontana@suse.de> Signed-off-by: Cho, Yu-Chen <acho@suse.com> Acked-by: David Hildenbrand <david@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210707105324.23400-8-acho@suse.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2021-06-21s390x/css: Add passthrough IRBEric Farman
Wire in the subchannel callback for building the IRB ESW and ECW space for passthrough devices, and copy the hardware's ESW into the IRB we are building. If the hardware presented concurrent sense, then copy that sense data into the IRB's ECW space. Signed-off-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20210617232537.1337506-5-farman@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2021-06-21s390x/css: Refactor IRB constructionEric Farman
Currently, all subchannel types have "sense data" copied into the IRB.ECW space, and a couple flags enabled in the IRB.SCSW and IRB.ESW. But for passthrough (vfio-ccw) subchannels, this data isn't populated in the first place, so enabling those flags leads to unexpected behavior if the guest tries to process the sense data (zeros) in the IRB.ECW. Let's add a subchannel callback that builds these portions of the IRB, and move the existing code into a routine for those virtual subchannels. The passthrough subchannels will be able to piggy-back onto this later. Signed-off-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20210617232537.1337506-4-farman@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2021-06-21s390x/css: Introduce an ESW structEric Farman
The Interrupt Response Block is comprised of several other structures concatenated together, but only the 12-byte Subchannel-Status Word (SCSW) is defined as a proper struct. Everything else is a simple array of 32-bit words. Let's define a proper struct for the 20-byte Extended-Status Word (ESW) so that we can make good decisions about the sense data that would go into the ECW area for virtual vs passthrough devices. [CH: adapted ESW definition to build with mingw, as discussed] Signed-off-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20210617232537.1337506-2-farman@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2021-03-26s390x: move S390_ADAPTER_SUPPRESSIBLEGerd Hoffmann
The definition S390_ADAPTER_SUPPRESSIBLE was moved to "cpu.h", per suggestion of Thomas Huth. From interface design perspective, IMHO, not a good thing as it belongs to the public interface of css_register_io_adapters(). We did this because CONFIG_KVM requeires NEED_CPU_H and Thomas, and other commenters did not like the consequences of that. Moving the interrupt related declarations to s390_flic.h was suggested by Cornelia Huck. Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Tested-by: Halil Pasic <pasic@linux.ibm.com> Message-Id: <20210317095622.2839895-2-kraxel@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-03-09Various spelling fixesMichael Tokarev
An assorted set of spelling fixes in various places. Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210309111510.79495-1-mjt@msgid.tls.msk.ru> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-02-08s390: Recognize confidential-guest-support optionDavid Gibson
At least some s390 cpu models support "Protected Virtualization" (PV), a mechanism to protect guests from eavesdropping by a compromised hypervisor. This is similar in function to other mechanisms like AMD's SEV and POWER's PEF, which are controlled by the "confidential-guest-support" machine option. s390 is a slightly special case, because we already supported PV, simply by using a CPU model with the required feature (S390_FEAT_UNPACK). To integrate this with the option used by other platforms, we implement the following compromise: - When the confidential-guest-support option is set, s390 will recognize it, verify that the CPU can support PV (failing if not) and set virtio default options necessary for encrypted or protected guests, as on other platforms. i.e. if confidential-guest-support is set, we will either create a guest capable of entering PV mode, or fail outright. - If confidential-guest-support is not set, guests might still be able to enter PV mode, if the CPU has the right model. This may be a little surprising, but shouldn't actually be harmful. To start a guest supporting Protected Virtualization using the new option use the command line arguments: -object s390-pv-guest,id=pv0 -machine confidential-guest-support=pv0 Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
2020-11-18s390x/pci: fix endianness issuesCornelia Huck
The zPCI group and function structures are big endian. However, we do not consistently store them as big endian locally, and are missing some conversions. Let's just store the structures as host endian instead and convert to big endian when actually handling the instructions retrieving the data. Also fix the layout of ClpReqQueryPciGrp: g is actually only 8 bit. This also fixes accesses on little endian hosts, and makes accesses on big endian hosts consistent. Fixes: 28dc86a07299 ("s390x/pci: use a PCI Group structure") Fixes: 9670ee752727 ("s390x/pci: use a PCI Function structure") Fixes: 1e7552ff5c34 ("s390x/pci: get zPCI function info from host") Signed-off-by: Cornelia Huck <cohuck@redhat.com> Tested-by: Matthew Rosato <mjrosato@linux.ibm.com> Tested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20201118104202.1301363-1-cohuck@redhat.com>
2020-11-05s390x: fix build for --without-default-devicesCornelia Huck
s390-pci-vfio.c calls into the vfio code, so we need it to be built conditionally on vfio (which implies CONFIG_LINUX). Fixes: cd7498d07fbb ("s390x/pci: Add routine to get the vfio dma available count") Reported-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-Id: <20201103123237.718242-1-cohuck@redhat.com> Acked-by: Greg Kurz <groug@kaod.org> Tested-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-11-01s390x/pci: get zPCI function info from hostMatthew Rosato
We use the capability chains of the VFIO_DEVICE_GET_INFO ioctl to retrieve the CLP information that the kernel exports. To be compatible with previous kernel versions we fall back on previous predefined values, same as the emulation values, when the ioctl is found to not support capability chains. If individual CLP capabilities are not found, we fall back on default values for only those capabilities missing from the chain. This patch is based on work previously done by Pierre Morel. Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> [aw: non-Linux build fixes] Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-11-01s390x/pci: use a PCI Function structurePierre Morel
We use a ClpRspQueryPci structure to hold the information related to a zPCI Function. This allows us to be ready to support different zPCI functions and to retrieve the zPCI function information from the host. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-11-01s390x/pci: use a PCI Group structurePierre Morel
We use a S390PCIGroup structure to hold the information related to a zPCI Function group. This allows us to be ready to support multiple groups and to retrieve the group information from the host. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-11-01s390x/pci: create a header dedicated to PCI CLPPierre Morel
To have a clean separation between s390-pci-bus.h and s390-pci-inst.h headers we export the PCI CLP instructions in a dedicated header. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-11-01s390x/pci: Honor DMA limits set by vfioMatthew Rosato
When an s390 guest is using lazy unmapping, it can result in a very large number of oustanding DMA requests, far beyond the default limit configured for vfio. Let's track DMA usage similar to vfio in the host, and trigger the guest to flush their DMA mappings before vfio runs out. Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> [aw: non-Linux build fixes] Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-11-01s390x/pci: Add routine to get the vfio dma available countMatthew Rosato
Create new files for separating out vfio-specific work for s390 pci. Add the first such routine, which issues VFIO_IOMMU_GET_INFO ioctl to collect the current dma available count. Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> [aw: Fix non-Linux build with CONFIG_LINUX] Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-11-01s390x/pci: Move header files to include/hw/s390xMatthew Rosato
Seems a more appropriate location for them. Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-10-02s390: guest support for diagnose 0x318Collin Walling
DIAGNOSE 0x318 (diag318) is an s390 instruction that allows the storage of diagnostic information that is collected by the firmware in the case of hardware/firmware service events. QEMU handles the instruction by storing the info in the CPU state. A subsequent register sync will communicate the data to the hypervisor. QEMU handles the migration via a VM State Description. This feature depends on the Extended-Length SCCB (els) feature. If els is not present, then a warning will be printed and the SCLP bit that allows the Linux kernel to execute the instruction will not be set. Availability of this instruction is determined by byte 134 (aka fac134) bit 0 of the SCLP Read Info block. This coincidentally expands into the space used for CPU entries, which means VMs running with the diag318 capability may not be able to read information regarding all CPUs unless the guest kernel supports an extended-length SCCB. This feature is not supported in protected virtualization mode. Signed-off-by: Collin Walling <walling@linux.ibm.com> Acked-by: Janosch Frank <frankja@linux.ibm.com> Acked-by: Thomas Huth <thuth@redhat.com> Acked-by: David Hildenbrand <david@redhat.com> Acked-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-Id: <20200915194416.107460-9-walling@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>