aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)Author
2019-02-05hw/moxie/Makefile.objs: Conditionally build moxieYang Zhong
CONFIG_MOXIE added for moxiesim board. Signed-off-by: Yang Zhong <yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-24-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/hppa/Makefile.objs: Create CONFIG_* for hppaYang Zhong
Add the new configs to default-configs/hppa-sofmmu.mak. Signed-off-by: Yang Zhong <yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20190202072456.6468-23-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/cris/Makefile.objs: Create CONFIG_* for crisYang Zhong
Add the new configs to default-configs/cris-sofmmu.mak. Signed-off-by: Yang Zhong <yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-22-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/alpha/Makefile.objs: Create CONFIG_* for alphaYang Zhong
Add the new configs to default-configs/alpha-sofmmu.mak. Signed-off-by: Yang Zhong <yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20190202072456.6468-21-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/sparc64/Makefile.objs: Create CONFIG_* for sparc64Yang Zhong
Add the new configs to default-configs/sparc64-sofmmu.mak. Signed-off-by: Yang Zhong <yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-20-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/riscv/Makefile.objs: Create CONFIG_* for riscv boardsYang Zhong
Add the new configs to default-configs/riscv*-sofmmu.mak. Signed-off-by: Yang Zhong <yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-19-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/nios2/Makefile.objs: Conditionally build nios2Yang Zhong
CONFIG_NIOS2_10M50 added for 10m50 dev board. Signed-off-by: Yang Zhong <yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-18-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/xtensa/Makefile.objs: Build xtensa_sim and xtensa_fpga conditionallyÁkos Kovács
Add the new CONFIG_* values to default-config/xtensa*-softmmu.mak. Signed-off-by: Ákos Kovács <akoskovacs@gmx.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Max Filippov <jcmvbkbc@gmail.com> Message-Id: <20190202072456.6468-17-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/lm32/Makefile.objs: Conditionally build lm32 and milkmystÁkos Kovács
CONFIG_LM32 and CONFIG_MILKYMIST added for lm32 and milkmyst build. Signed-off-by: Ákos Kovács <akoskovacs@gmx.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-16-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/sparc/Makefile.objs: CONFIG_* for sun4m and leon3 createdÁkos Kovács
CONFIG_LEON3 added to default-configs/sparc-softmmu.mak. Signed-off-by: Ákos Kovács <akoskovacs@gmx.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-15-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/s390/Makefile.objs: Create new CONFIG_* variables for s390x boards and ↵Paolo Bonzini
devices Make hw/s390x configurable and add new CONFIG_* to the default-configs/s390x*-softmmu.mak. This will be used to enable/disable vfio-ccw. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-14-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/sh4/Makefile.objs: New CONFIG_* varibales created for sh4 boards and deviceÁkos Kovács
Make hw/sh4 configurable and add new CONFIG_* to the default-configs/sh4*-softmmu.mak. Signed-off-by: Ákos Kovács <akoskovacs@gmx.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-13-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/ppc/Makefile.objs: Build all boards conditinally with CONFIG_*Ákos Kovács
CONFIG_PPC405, CONFIG_PPC440, CONFIG_MAC_OLDWORLD, CONFIG_MAX_NEWWORLD and CONFIG_VIRTEX configuration options created for default-configs/ppc*-softmmu.mak. Signed-off-by: Ákos Kovács <akoskovacs@gmx.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-12-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/mips/Makefile.objs: Create CONFIG_* for r4k, malta, mipssim boardsÁkos Kovács
Add the new configs to default-configs/mips*-sofmmu.mak. Signed-off-by: Ákos Kovács <akoskovacs@gmx.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-11-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/microblaze/Makefile.objs: Create configs for petalogix and xilinx boardsÁkos Kovács
CONFIG_PETALOGIX_* and CONFIG_XLNX_* configs added to default-configs/microblaze-softmmu.mak and default-configs/microblazeel-softmmu.mak. Signed-off-by: Ákos Kovács <akoskovacs@gmx.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-10-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/m68k/Makefile.objs: Conditionally build boardsÁkos Kovács
CONFIG_AN5206, CONFIG_MCF5206 and CONFIG_MCF5208 make variables created for m68k boards, and added to default-configs/m86k-softmmu.mak. Signed-off-by: Ákos Kovács <akoskovacs@gmx.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-9-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/arm/Makefile.objs: CONFIG_ARM_VIRT created for virt boardYang Zhong
Make ARM virt code configurable and the new CONFIG_ARM_VIRT definitions added to the default-configs/arm-softmmu.mak. Signed-off-by: Yang Zhong <yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-8-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/i386/Makefile.objs: Build pc_piix* and pc_q35 boardsPaolo Bonzini
CONFIG_PIIX and CONFIG_Q35 created for the pc board object files. These are enabled automatically at default-configs/i386-softmmu.mak and default-configs/x86_64-softmmu.mak Signed-off-by: Ákos Kovács <akoskovacs@gmx.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-7-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05build: actually use CONFIG_PAMPaolo Bonzini
Do not link it unconditionally into all binaries. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-6-yang.zhong@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/pci-host/Makefile.objs: make CONFIGS clear for PCI EXPRESSYang Zhong
Change the CONFIGs for PCI EXPRESS and make module name more clear for code files. Signed-off-by: Yang Zhong <yang.zhong@intel.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-5-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05vfio: move conditional up to hw/Makefile.objsPaolo Bonzini
Instead of wrapping the entire Makefile.objs with an ifeq/endif, just include the directory only for Linux. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-4-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05ide: split ioport registration to a separate filePaolo Bonzini
This is not needed on ARM, and brings in ISA bus code which is otherwise not necessary. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190202072456.6468-3-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05scsi-generic: avoid possible out-of-bounds access to r->bufPaolo Bonzini
Whenever the allocation length of a SCSI request is shorter than the size of the VPD page list, page_idx is used blindly to index into r->buf. Even though the stores in the insertion sort are protected against overflows, the same is not true of the reads and the final store of 0xb0. This basically does the same thing as commit 57dbb58d80 ("scsi-generic: avoid out-of-bounds access to VPD page list", 2018-11-06), except that here the allocation length can be chosen by the guest. Note that according to the SCSI standard, the contents of the PAGE LENGTH field are not altered based on the allocation length. The code was introduced by commit 6c219fc8a1 ("scsi-generic: keep VPD page list sorted", 2018-11-06) but the overflow was already possible before. Reported-by: Kevin Wolf <kwolf@redhat.com> Fixes: a71c775b24ebc664129eb1d9b4c360590353efd5 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05i386: allow to load initrd below 4 GB for recent linuxLi Zhijian
Since linux commit: cf8fa920cb42 ("i386: handle an initrd in highmem (version 2)") linux has supported initrd up to 4 GB, but the header field ramdisk_max is still set to 2 GB to avoid "possible bootloader bugs". When use '-kernel vmlinux -initrd initrd.cgz' to launch a VM, the firmware(it could be linuxboot_dma.bin) helps to read initrd contents into guest memory(below ramdisk_max) and jump to kernel. that's similar with what bootloader does, like grub. In addition, initrd_max is uint32_t simply because QEMU doesn't support the 64-bit boot protocol (specifically the ext_ramdisk_image field). Therefore here just limit initrd_max to UINT32_MAX simply as well to allow initrd to be loaded below 4 GB. NOTE: it's possible that linux protocol within [0x208, 0x20c] supports up to 4 GB initrd as well. CC: Paolo Bonzini <pbonzini@redhat.com> CC: Richard Henderson <rth@twiddle.net> CC: Eduardo Habkost <ehabkost@redhat.com> CC: "Michael S. Tsirkin" <mst@redhat.com> CC: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05i386: import & use bootparam.hLi Zhijian
it's from v4.20-rc5. CC: Stefano Garzarella <sgarzare@redhat.com> CC: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/core/loader.c: Read as long as possible in load_image_size()Li Zhijian
Don't expect read(2) can always read as many as it's told. CC: Richard Henderson <richard.henderson@linaro.org> CC: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/i386/pc: enable PVH only for machine type >= 4.0Stefano Garzarella
In order to avoid migration issues, we enable PVH only for machine type >= 4.0 Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05hw/i386/pc: use PVH option romStefano Garzarella
Use pvh.bin option rom when we are booting an uncompressed kernel using the x86/HVM direct boot ABI. Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Based-on: <1547554687-12687-1-git-send-email-liam.merwick@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05pvh: load initrd and expose it through fw_cfgStefano Garzarella
When initrd is specified, load and expose it to the guest firmware through fw_cfg. The firmware will fill the hvm_start_info for the kernel. Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Based-on: <1545422632-24444-5-git-send-email-liam.merwick@oracle.com> Signed-off-by: Liam Merwick <Liam.Merwick@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05pvh: Boot uncompressed kernel using direct boot ABILiam Merwick
These changes (along with corresponding Linux kernel and qboot changes) enable a guest to be booted using the x86/HVM direct boot ABI. This commit adds a load_elfboot() routine to pass the size and location of the kernel entry point to qboot (which will fill in the start_info struct information needed to to boot the guest). Having loaded the ELF binary, load_linux() will run qboot which continues the boot. The address for the kernel entry point is read from an ELF Note in the uncompressed kernel binary by a helper routine passed to load_elf(). Co-developed-by: George Kennedy <George.Kennedy@oracle.com> Signed-off-by: George Kennedy <George.Kennedy@oracle.com> Signed-off-by: Liam Merwick <liam.merwick@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05elf: Add optional function ptr to load_elf() to parse ELF notesLiam Merwick
This patch adds an optional function pointer, 'elf_note_fn', to load_elf() which causes load_elf() to additionally parse any ELF program headers of type PT_NOTE and check to see if the ELF Note is of the type specified by the 'translate_opaque' arg. If a matching ELF Note is found then the specfied function pointer is called to process the ELF note. Passing a NULL function pointer results in ELF Notes being skipped. The first consumer of this functionality is the PVHboot support which needs to read the XEN_ELFNOTE_PHYS32_ENTRY ELF Note while loading the uncompressed kernel binary in order to discover the boot entry address for the x86/HVM direct boot ABI. Signed-off-by: Liam Merwick <liam.merwick@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05Merge remote-tracking branch 'remotes/xtensa/tags/20190204-xtensa' into stagingPeter Maydell
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 Hildenbrand
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 Hildenbrand
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 Hildenbrand
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 Hildenbrand
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 Maydell
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 Huck
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 Hildenbrand
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 Hildenbrand
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 Durrant
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 Durrant
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 Huth
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 Kardashevskiy
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 Huth
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 Kardashevskiy
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 Huth
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 Goater
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 Goater
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 Goater
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>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-16 09:44:56 +0000