aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2019-02-06sun4m: pass initrd size to OpenBIOS via fw_cfg interfaceMark Cave-Ayland1-11/+14
This is to enable OpenBIOS to claim the initrd memory as in-use before attempting to boot the kernel. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2019-02-06sun4u: add power_mem_read routinePrasad J Pandit1-0/+6
Define skeleton 'power_mem_read' routine. Avoid NULL dereference. Reported-by: Fakhri Zulkifli <mohdfakhrizulkifli@gmail.com> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2019-02-06hw/sparc64: Create VGA device only if it has really been requestedThomas Huth1-1/+9
The sun4u/sun4v machine currently always creates a VGA device, even if the user started QEMU with "-nodefaults" or "-vga none". That's likely not what the users expect in this case, so add a check whether the VGA adapter has really been requested. Signed-off-by: Thomas Huth <huth@tuxfamily.org> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2019-02-05Merge remote-tracking branch ↵Peter Maydell1-70/+96
'remotes/pmaydell/tags/pull-target-arm-20190205' into staging target-arm queue: * Implement Armv8.5-BTI extension for system emulation mode * Implement the PR_PAC_RESET_KEYS prctl() for linux-user mode's Armv8.3-PAuth support * Support TBI (top-byte-ignore) properly for linux-user mode * gdbstub: allow killing QEMU via vKill command * hw/arm/boot: Support DTB autoload for firmware-only boots * target/arm: Make FPSCR/FPCR trapped-exception bits RAZ/WI # gpg: Signature made Tue 05 Feb 2019 17:04:22 GMT # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * remotes/pmaydell/tags/pull-target-arm-20190205: (22 commits) target/arm: Make FPSCR/FPCR trapped-exception bits RAZ/WI hw/arm/boot: Support DTB autoload for firmware-only boots hw/arm/boot: Clarify why arm_setup_firmware_boot() doesn't set env->boot_info hw/arm/boot: Factor out "set up firmware boot" code hw/arm/boot: Factor out "direct kernel boot" code into its own function hw/arm/boot: Fix block comment style in arm_load_kernel() gdbstub: allow killing QEMU via vKill command target/arm: Enable TBI for user-only target/arm: Compute TB_FLAGS for TBI for user-only target/arm: Clean TBI for data operations in the translator target/arm: Add TBFLAG_A64_TBID, split out gen_top_byte_ignore tests/tcg/aarch64: Add pauth smoke test linux-user: Implement PR_PAC_RESET_KEYS target/arm: Enable BTI for -cpu max target/arm: Set btype for indirect branches target/arm: Reset btype for direct branches target/arm: Default handling of BTYPE during translation target/arm: Cache the GP bit for a page in MemTxAttrs exec: Add target-specific tlb bits to MemTxAttrs target/arm: Add BT and BTYPE to tb->flags ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-02-05Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190205' into stagingPeter Maydell2-85/+163
Fixes and improvements in tcg and the zPCI code. # gpg: Signature made Tue 05 Feb 2019 16:36:09 GMT # gpg: using RSA key C3D0D66DC3624FF6A8C018CEDECF6B93C6F02FAF # gpg: issuer "cohuck@redhat.com" # gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>" [unknown] # gpg: aka "Cornelia Huck <huckc@linux.vnet.ibm.com>" [full] # gpg: aka "Cornelia Huck <cornelia.huck@de.ibm.com>" [full] # gpg: aka "Cornelia Huck <cohuck@kernel.org>" [unknown] # gpg: aka "Cornelia Huck <cohuck@redhat.com>" [unknown] # Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0 18CE DECF 6B93 C6F0 2FAF * remotes/cohuck/tags/s390x-20190205: s390x/pci: Unplug remaining requested devices on pcihost reset s390x/pci: Warn when adding PCI devices without the 'zpci' feature s390x/pci: Fix hotplugging of PCI bridges s390x/pci: Fix primary bus number for PCI bridges s390x/tcg: Don't model FP registers as globals s390x/pci: mark zpci devices as unmigratable s390x/pci: Drop release timer and replace it with a flag s390x/pci: Introduce unplug requests and split unplug handler s390x: remove direct reference to mem_path global from s390x code target/s390x: define TCG_GUEST_DEFAULT_MO for MTTCG Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-02-05hw/arm/boot: Support DTB autoload for firmware-only bootsPeter Maydell1-1/+0
The arm_boot_info struct has a skip_dtb_autoload flag: if this is set to true by the board code then arm_load_kernel() will not load the DTB itself, but will leave this for the board code to do itself later. However, the check for this is done in a code path which is only executed for the case where we load a kernel image file. If we're taking the "boot via firmware" code path then the flag isn't honoured and the DTB is never loaded. We didn't notice this because the only real user of "boot via firmware" that cares about the DTB is the virt board (for UEFI boot), and that always wants skip_dtb_autoload anyway. But the SBSA reference board model we're planning to add will want the flag to behave correctly. Now we've refactored the arm_load_kernel() function, the fix is simple: drop the early 'return' so we fall into the same "load the DTB" code the boot-direct-kernel path uses. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20190131112240.8395-6-peter.maydell@linaro.org
2019-02-05hw/arm/boot: Clarify why arm_setup_firmware_boot() doesn't set env->boot_infoPeter Maydell1-1/+2
The code path for booting firmware doesn't set env->boot_info. At first sight this looks odd, so add a comment saying why we don't. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20190131112240.8395-5-peter.maydell@linaro.org
2019-02-05hw/arm/boot: Factor out "set up firmware boot" codePeter Maydell1-43/+49
Factor out the "boot via firmware" code path from arm_load_kernel() into its own function. This commit only moves code around; no semantic changes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20190131112240.8395-4-peter.maydell@linaro.org
2019-02-05hw/arm/boot: Factor out "direct kernel boot" code into its own functionPeter Maydell1-70/+80
Factor out the "direct kernel boot" code path from arm_load_kernel() into its own function; this function is getting long enough that the code flow is a bit confusing. This commit only moves code around; no semantic changes. We leave the "load the dtb" code in arm_load_kernel() -- this is currently only used by the "direct kernel boot" path, but this is a bug which we will fix shortly. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20190131112240.8395-3-peter.maydell@linaro.org
2019-02-05hw/arm/boot: Fix block comment style in arm_load_kernel()Peter Maydell1-10/+20
Fix the block comment style in arm_load_kernel() to QEMU's current style preferences. This will allow us to do some refactoring of this function without checkpatch complaining about the code-motion patches. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20190131112240.8395-2-peter.maydell@linaro.org
2019-02-05Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell9-16/+30
pci, pc, virtio: fixes, cleanups, features vhost user blk discard/write zeroes features misc cleanups and fixes all over the place Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Tue 05 Feb 2019 16:00:20 GMT # gpg: using RSA key 281F0DB8D28D5469 # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full] # 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 * remotes/mst/tags/for_upstream: contrib/libvhost-user: cleanup casts r2d: fix build on mingw mmap-alloc: fix hugetlbfs misaligned length in ppc64 mmap-alloc: unfold qemu_ram_mmap() i386, acpi: cleanup build_facs by removing second unused argument fw_cfg: fix the life cycle and the name of "qemu_extra_params_fw" acpi: Make TPM 2.0 with TIS available as MSFT0101 hw/virtio: Use CONFIG_VIRTIO_PCI switch instead of CONFIG_PCI vhost-user-blk: add discard/write zeroes features support contrib/vhost-user-blk: fix the compilation issue pci/msi: export msi_is_masked() intel_iommu: reset intr_enabled when system reset intel_iommu: fix operator in vtd_switch_address_space hw: virtio-pci: drop DO_UPCAST include: update Linux headers to 4.21-rc1/5.0-rc1 scripts/update-linux-headers.sh: adjust for Linux 4.21-rc1 (or 5.0-rc1) contrib/libvhost-user: switch to uint64_t virtio: add checks for the size of the indirect table Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-02-05r2d: fix build on mingwMichael S. Tsirkin1-1/+1
Comment near strncpy explains kernel_cmdline does not need to be 0-terminated. Accordingly mark it as QEMU_NONSTRING. Without this, gcc warns: 'strncpy' specified bound 256 equals destination size Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-05i386, acpi: cleanup build_facs by removing second unused argumentWei Yang1-2/+2
The second argument of build_facs() is not used, just remove it. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-02-05fw_cfg: fix the life cycle and the name of "qemu_extra_params_fw"Laszlo Ersek1-4/+5
Commit 19bcc4bc3213 ("fw_cfg: Make qemu_extra_params_fw locally", 2019-01-04) changed the storage duration of the "qemu_extra_params_fw" array from static to automatic. This broke the interface contract on the fw_cfg_add_file() function, which is documented as follows, in "include/hw/nvram/fw_cfg.h": > [...] The data referenced by the starting pointer is only linked, NOT > copied, into the data structure of the fw_cfg device. [...] As a result, when guest firmware fetches the "etc/boot-menu-wait" fw_cfg file, it now sees garbage. Fix the regression by changing the storage duration to allocated. (The call is reached at most once, on the realize path of the board-specific fw_cfg sysbus device.) While at it, clean up the name and the assignment of the object as well. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Fixes: 19bcc4bc3213e78c303ad480a7a578f62258252d Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-02-05acpi: Make TPM 2.0 with TIS available as MSFT0101Stefan Berger1-2/+10
This patch makes the a TPM 2.0 with TIS interface available under the HID 'MSF0101'. This is supported by Linux and also Windows now recognizes the TPM 2.0 with TIS interface. Leave the TPM 1.2 as before. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2019-02-05hw/virtio: Use CONFIG_VIRTIO_PCI switch instead of CONFIG_PCIThomas Huth1-1/+1
For downstream s390x builds, we'd like to be able to build QEMU with CONFIG_VIRTIO_PCI disabled (since virtio-ccw is used here instead), but still with CONFIG_PCI enabled. This currently fails since the virtio-*-pci.o files are still included in the build, but virtio-pci.o is missing. Use the right config switch CONFIG_VIRTIO_PCI to exclude the virtio-*-pci.o files from the build. Reported-by: Miroslav Rezanina <mrezanin@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-05vhost-user-blk: add discard/write zeroes features supportChangpeng Liu1-0/+4
Linux commit 1f23816b8 "virtio_blk: add discard and write zeroes support" added the support in the Guest kernel, while here also enable the features support with vhost-user-blk driver. Also enable the test example utility with DISCARD and WRITE ZEROES commands. Signed-off-by: Changpeng Liu <changpeng.liu@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-05pci/msi: export msi_is_masked()Peter Xu1-1/+1
It is going to be used later on outside MSI code to detect whether one MSI vector is masked out. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-05intel_iommu: reset intr_enabled when system resetPeter Xu1-0/+1
This is found when I was debugging another problem. Until now no bug is reported with this but we'd better reset the IR status correctly after a system reset. Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-05intel_iommu: fix operator in vtd_switch_address_spacePeter Xu1-1/+1
When calculating use_iommu, we wanted to first detect whether DMAR is enabled, then check whether PT is enabled if DMAR is enabled. However in the current code we used "&" rather than "&&" so the ordering requirement is lost (instead it'll be an "AND" operation). This could introduce errors dumped in QEMU console when rebooting a guest with both assigned device and vIOMMU, like: qemu-system-x86_64: vtd_dev_to_context_entry: invalid root entry: rsvd=0xf000ff53f000e2c3, val=0xf000ff53f000ff53 (reserved nonzero) Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-05hw: virtio-pci: drop DO_UPCASTLi Qiang1-2/+2
Use VIRTIO_PCI MACRO instead. Signed-off-by: Li Qiang <liq3ea@163.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-05Merge remote-tracking branch 'remotes/xtensa/tags/20190204-xtensa' into stagingPeter Maydell4-38/+429
target/xtensa: SMP updates and various fixes - fix CPU wakeup on runstall changes; expose runstall as an IRQ line; - place mini-bootloader at the BSP reset vector; - expose CPU core frequency in XTFPGA board FPGA register; - rearrange access to external interrupts of xtensa cores; - add MX interrupt distributor and use it on SMP XTFPGA boards; - add test_mmuhifi_c3 xtensa core variant; - raise number of CPUs that can be instantiated on XTFPGA boards. # gpg: Signature made Mon 04 Feb 2019 18:59:32 GMT # gpg: using RSA key 2B67854B98E5327DCDEB17D851F9CC91F83FA044 # gpg: issuer "jcmvbkbc@gmail.com" # gpg: Good signature from "Max Filippov <filippov@cadence.com>" [unknown] # gpg: aka "Max Filippov <max.filippov@cogentembedded.com>" [full] # gpg: aka "Max Filippov <jcmvbkbc@gmail.com>" [full] # Primary key fingerprint: 2B67 854B 98E5 327D CDEB 17D8 51F9 CC91 F83F A044 * remotes/xtensa/tags/20190204-xtensa: hw/xtensa: xtfpga: raise CPU number limit target/xtensa: add test_mmuhifi_c3 core hw/xtensa: xtfpga: use MX PIC for SMP target/xtensa: add MX interrupt controller target/xtensa: expose core runstall as an IRQ line target/xtensa: rearrange access to external interrupts target/xtensa: drop function xtensa_timer_irq target/xtensa: fix access to the INTERRUPT SR hw/xtensa: xtfpga: use core frequency hw/xtensa: xtfpga: fix bootloader placement in SMP target/xtensa: add qemu_cpu_kick to xtensa_runstall Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-02-05s390x/pci: Unplug remaining requested devices on pcihost resetDavid Hildenbrand1-0/+15
When resetting the guest we should unplug and remove all devices that are still pending. With this patch, the requested device will be unplugged on reboot (S390_RESET_EXTERNAL and S390_RESET_REIPL, which reset the pcihost bridge via qemu_devices_reset()). This approach is similar to what's done for acpi PCI hotplug in acpi_pcihp_reset() -> acpi_pcihp_update() -> acpi_pcihp_update_hotplug_bus() -> acpi_pcihp_eject_slot(). s390_pci_generate_plug_event()'s will still be generated, I guess this is not an issue. The same thing would happen right now when unplugging a device just before starting the guest. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190130155733.32742-7-david@redhat.com> Reviewed-by: Collin Walling <walling@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-05s390x/pci: Warn when adding PCI devices without the 'zpci' featureDavid Hildenbrand1-0/+6
We decided to always create the PCI host bridge, even if 'zpci' is not enabled (due to migration compatibility). This however right now allows to add zPCI/PCI devices to a VM although the guest will never actually see them, confusing people that are using a simple CPU model that has no 'zpci' enabled - "Why isn't this working" (David Hildenbrand) Let's check for 'zpci' and at least print a warning that this will not work as expected. We could also bail out, however that might break existing QEMU commandlines. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190130155733.32742-4-david@redhat.com> Reviewed-by: Collin Walling <walling@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-05s390x/pci: Fix hotplugging of PCI bridgesDavid Hildenbrand1-9/+19
When hotplugging a PCI bridge right now to the root port, we resolve pci_get_bus(pdev)->parent_dev, which results in a SEGFAULT. Hotplugging really only works right now when hotplugging to another bridge. Instead, we have to properly check if we are already at the root. Let's cleanup the code while at it a bit and factor out updating the subordinate bus number into a separate function. The check for "old_nr < nr" is right now not strictly necessary, but makes it more obvious what is actually going on. Most probably fixing up the topology is not our responsibility when hotplugging. The guest has to sort this out. But let's keep it for now and only fix current code to not crash. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190130155733.32742-3-david@redhat.com> Reviewed-by: Collin Walling <walling@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-05s390x/pci: Fix primary bus number for PCI bridgesDavid Hildenbrand1-5/+8
The primary bus number corresponds always to the bus number of the bus the bridge is attached to. Right now, if we have two bridges attached to the same bus (e.g. root bus) this is however not the case. The first bridge will have primary bus 0, the second bridge primary bus 1, which is wrong. Fix the assignment. While at it, drop setting the PCI_SUBORDINATE_BUS temporarily to 0xff. Setting it temporarily to that value (as discussed e.g. in [1]), is only relevant for a running system that probes the buses. The value is effectively unused for us just doing a DFS. Also add a comment why we have to reassign during every reset (which I found to be surprising. Please note that hotplugging of bridges is in general still broken, will be fixed next. [1] http://www.science.unitn.it/~fiorella/guidelinux/tlk/node76.html Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190130155733.32742-2-david@redhat.com> Reviewed-by: Collin Walling <walling@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-04Merge remote-tracking branch 'remotes/aperard/tags/pull-xen-20190204' into ↵Peter Maydell4-20/+57
staging Xen queue * xen-block, the Xen PV backend, now handles resize. * configure cleanup. * xen-bus fix. # gpg: Signature made Mon 04 Feb 2019 11:16:13 GMT # gpg: using RSA key F80C006308E22CFD8A92E7980CF5572FD7FB55AF # gpg: issuer "anthony.perard@citrix.com" # gpg: Good signature from "Anthony PERARD <anthony.perard@gmail.com>" [marginal] # gpg: aka "Anthony PERARD <anthony.perard@citrix.com>" [marginal] # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: 5379 2F71 024C 600F 778A 7161 D8D5 7199 DF83 42C8 # Subkey fingerprint: F80C 0063 08E2 2CFD 8A92 E798 0CF5 572F D7FB 55AF * remotes/aperard/tags/pull-xen-20190204: xen-block: handle resize callback xen: fix xen-bus state model to allow frontend re-connection configure: Don't add Xen's libs to LDFLAGS configure: xen: Stop build-testing for xc_domain_create Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-02-04s390x/pci: mark zpci devices as unmigratableCornelia Huck1-0/+10
We currently don't migrate any state for zpci devices, which are coupled with standard pci devices. This means funny things happen when we e.g. try to migrate with a virtio-pci device but the s390x- specific zpci state is not migrated (vfio-pci is not affected, as it is not migratable anyway.) Until this is fixed, mark zpci devices as unmigratable. Reported-by: David Hildenbrand <david@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Collin Walling <walling@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-04s390x/pci: Drop release timer and replace it with a flagDavid Hildenbrand2-33/+8
Let's handle it similar to x86 ACPI PCI code and don't use a timer. Instead, remember if an unplug request is pending and keep it pending for eternity. (a follow up patch will process the request on reboot). We expect that a guest that is up and running, will process the unplug request and trigger the unplug. This is normal operation, no timer needed. If the guest does not react, this usually means something in the guest is going wrong. Simply removing the device after 30 seconds does not really sound like a good idea. It might sometimes be wanted, but I consider this rather an "opt-in" decision as it might harm a guest not prepared for it. If we ever actually want a "forced/surprise removal", we will have to implement something on top of the existing "device_del" framework. E.g. also x86 might want to do a forced/surprise removal of PCI devices under some conditions. "device_del X, forced=true" could be an option and will require changes to the hotplug handler infrastructure. This will then move the responsibility on when to do a forced removal to a higher level. Doing a forced removal right now over-complicates things and doesn't really seem to be required. Let's allow to send multiple requests. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190130155733.32742-6-david@redhat.com> Reviewed-by: Collin Walling <walling@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-04s390x/pci: Introduce unplug requests and split unplug handlerDavid Hildenbrand2-54/+113
PCI on s390x is really weird and how it was modeled in QEMU might not have been the right choice. Anyhow, right now it is the case that: - Hotplugging a PCI device will silently create a zPCI device (if none is provided) - Hotunplugging a zPCI device will unplug the PCI device (if any) - Hotunplugging a PCI device will unplug also the zPCI device As far as I can see, we can no longer change this behavior. But we should fix it. Both device types are handled via a single hotplug handler call. This is problematic for various reasons: 1. Unplugging via the zPCI device allows to unplug devices that are not hot removable. (check performed in qdev_unplug()) - bad. 2. Hotplug handler chains are not possible for the unplug case. In the future, the machine might want to override hotplug handlers, to process device specific stuff and to then branch off to the actual hotplug handler. We need separate hotplug handler calls for both the PCI and zPCI device to make this work reliably. All other PCI implementations are already prepared to handle this correctly, only s390x is missing. Therefore, introduce the unplug_request handler and properly perform unplug checks by redirecting to the separate unplug_request handlers. When finally unplugging, perform two separate hotplug_handler_unplug() calls, first for the PCI device, followed by the zPCI device. This now nicely splits unplugging paths for both devices. The redirect part is a little hairy, as the user is allowed to trigger unplug either via the PCI or the zPCI device. So redirect always to the PCI unplug request handler first and remember if that check has been performed in the zPCI device. Redirect then to the zPCI device unplug request handler to perform the magic. Remembering that we already checked the PCI device breaks the redirect loop. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190130155733.32742-5-david@redhat.com> Reviewed-by: Collin Walling <walling@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-04xen-block: handle resize callbackPaul Durrant3-7/+38
Some frontend drivers will handle dynamic resizing of PV disks, so set up the BlockDevOps resize_cb() method during xen_block_realize() to allow this to be done. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-02-04xen: fix xen-bus state model to allow frontend re-connectionPaul Durrant1-13/+19
There is a flaw in the xen-bus state model. To allow a frontend to re- connect the backend state of an online XenDevice is transitioned from Closed to InitWait, but this is currently done unilaterally which is incorrect. The backend state should remain Closed until the frontend state transitions to Initialising. This patch removes the automatic backend state transition from xen_device_backend_state_changed() and, instead, adds an extra check in xen_device_frontend_state_changed() to determine whether a frontend is trying to re-connect to a previously Closed XenDevice. Only if this is found to be the case is the backend state transitioned from Closed to InitWait. Note that this transition will be common amongst all XenDevice classes and hence xen_device_frontend_state_changed() returns immediately afterwards without calling into the XenDeviceClass frontend_changed() method. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-02-04hw/ppc: Don't include m48t59.h if it is not necessaryThomas Huth4-5/+0
These files don't use anything from m48t59.h, so no need to include this header here. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04spapr_pci: Fix endianness in assigned-addresses propertyAlexey Kardashevskiy1-1/+1
reg->phys_hi and assigned->phys_hi are big endian but we do an extra byteswap anyway when copying reg->phys_hi to assigned->phys_hi. To make things slightly more messy, we also add a relocatable bit (b_n()) although in the right endianness. This fixes endianness of assigned->phys_hi. This is unlikely to produce any visible difference though as we should end up there only in the case of PCI hotplug and even then I am not sure if (d->io_regions[i].addr == PCI_BAR_UNMAPPED) == true. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04hw/ppc/spapr: Add support for "-vga cirrus"Thomas Huth1-0/+1
The cirrus VGA card has been enabled in the PPC builds with commit 29f9cef39eb1ae55e82c ("ppc: Include vga cirrus card into the compiling process") last year. It also works on the pseries machine, even SLOF contains support for this card, so we can also support this for the "-vga" parameter here. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04spapr: Drop unused parameters from fdt building helperAlexey Kardashevskiy1-5/+3
spapr_load_rtas() handles now RTAS address and size information in the FDT so drop them from spapr_build_fdt(). While we are here, fix a small typo. Fixes: 3f5dabceba24 "pseries: Consolidate construction of /rtas device tree node" Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04hw/ppc: Move ppc40x_*reset() functions from ppc405_uc.c to ppc.cThomas Huth3-60/+57
Currently, it is not possible to build a QEMU binary without the ppc405_uc.c file, even if you do not want to have the embedded machines in the binary. This is bad since it's quite a bit of code and this code pulls in some more dependencies (e.g. via the usage of serial_mm_init()) which would not be needed otherwise - especially with the upcoming Kconfig-style configuration system for QEMU. The only functions from this file which are really always required for linking are the ppc40x_*reset() functions, so move these functions to ppc.c, close to the ppc40x_set_irq() function that calls them. Now we can flag ppc405_uc.c and ppc4xx_devs.c with the CONFIG_PPC4XX config switch, too. And while we're at it, replace the printf()s in these ppc40x_*reset() functions with proper calls to qemu_log_mask(). Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04spapr: move the interrupt presenters under machine_dataCédric Le Goater5-18/+23
Next step is to remove them from under the PowerPCCPU Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04ppc/pnv: introduce a CPU machine_dataCédric Le Goater2-4/+15
Include the interrupt presenter under the machine_data as we plan to remove it from under PowerPCCPU Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04xive: add a get_tctx() method to the XiveRouterCédric Le Goater2-6/+18
It provides a mean to retrieve the XiveTCTX of a CPU. This will become necessary with future changes which move the interrupt presenter object pointers under the PowerPCCPU machine_data. The PowerNV machine has an extra requirement on TIMA accesses that this new method addresses. The machine can perform indirect loads and stores on the TIMA on behalf of another CPU. The PIR being defined in the controller registers, we need a way to peek in the controller model to find the PIR value. The XiveTCTX is moved above the XiveRouter definition to avoid forward typedef declarations. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04spapr/pci: Fix primary bus number for PCI bridgesDavid Hildenbrand1-4/+1
While looking at the s390x implementation, looks like spapr has a similar BUG when building the topology. The primary bus number corresponds always to the bus number of the bus the bridge is attached to. Right now, if we have two bridges attached to the same bus (e.g. root bus) this is however not the case. The first bridge will have primary bus 0, the second bridge primary bus 1, which is wrong. Fix the assignment. While at it, drop setting the PCI_SUBORDINATE_BUS temporarily to 0xff. Setting it temporarily to that value (as discussed e.g. in [1]), is only relevant for a running system that probes the buses. The value is effectively unused for us just doing a DFS. [1] http://www.science.unitn.it/~fiorella/guidelinux/tlk/node76.html Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04spapr: Forbid setting ic-mode for old machine typesGreg Kurz1-0/+5
Machine types 3.0 and older only know about the legacy XICS backend. Make it clear by erroring out if the user tries to set ic-mode on such machines. Signed-off-by: Greg Kurz <groug@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04hw/ppc/spapr: Encode the SCSI channel (bus) in the SRP LUNsThomas Huth1-3/+4
In hw/scsi/spapr_vio.c we declare that the controller supports multiple buses by specifying "max_channel = 7" there. So in the code that fixes up the device tree nodes, we must encode the channel number (a.k.a. bus number in the "Logical unit addressing format" table of SAM5) into the 64-bit LUN, too. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1663160 Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04spapr/vio: remove the "irq" property"Cédric Le Goater1-41/+6
commit efe2add7cb7f ("spapr/vio: deprecate the "irq" property") was merged in QEMU version 3.0. The "irq" property" can be removed for QEMU version 4.0. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04ppc440: Avoid reporting error when reading non-existent RAM slotBALATON Zoltan1-2/+4
When reading base register of RAM slot with no RAM we should not try to calculate register value because that will result printing an error due to invalid RAM size. Just return 0 without the error in this case. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04ppc/xive: fix remaining XiveFabric namesCédric Le Goater1-3/+3
Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04sam460ex: Fix support for memory larger than 1GBBALATON Zoltan2-12/+16
Fix the encoding of larger memory modules in the SoC registers which allows specifying more than 1GB memory for sam460ex. Well, only 2GB due to SoC and firmware restrictions which was the only missing value compared to what the real hardware supports. The SoC should support up to 4GB but when setting that the firmware hangs during memory test. This may be an overflow bug in the firmware which I did not try to debug but this may affect real hardware as well. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04ppc4xx: Pass array index to function instead of pointer into the arrayBALATON Zoltan2-44/+36
The sdram_set_bcr() function in ppc440_uc.c takes a pointer into an array then calculates its index from that. It's simpler and easier to just pass the index which simplifies both the function and its callers. Do similar cleanup in ppc4xx_devs.c to similar function. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04ppc4xx: Rename ppc4xx_sdram_t in ppc440_uc.c to ppc440_sdram_tBALATON Zoltan1-8/+8
There's already a struct with the same name in ppc4xx_devs.c. They are not used outside their files so don't clash but they are also not identical so rename the ppc440 specific one to distinguish them. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-04ppc4xx: Use ram_addr_t in ppc4xx_sdram_adjust()BALATON Zoltan3-4/+4
To avoid overflow if larger values are added later use ram_addr_t for the sdram_bank_sizes parameter to match ram_size to which it is compared. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
generated by cgit v1.1 at 2024-08-24 09:20:49 +0000