aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-03-16via-ide: ensure that PCI_INTERRUPT_LINE is hard-wired to its default valueMark Cave-Ayland
Some firmwares accidentally write to PCI_INTERRUPT_LINE on startup which has no effect on real hardware since it is hard-wired to its default value, but causes the guest OS to become confused trying to initialise IDE devices when running under QEMU. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20200313082444.2439-5-mark.cave-ayland@ilande.co.uk Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-16pci: Honour wmask when resetting PCI_INTERRUPT_LINEBALATON Zoltan
The pci_do_device_reset() function (called from pci_device_reset) clears the PCI_INTERRUPT_LINE config reg of devices on the bus but did this without taking wmask into account. We'll have a device model now that needs to set a constant value for this reg and this patch allows to do that without additional workaround in device emulation to reverse the effect of this PCI bus reset function. Suggested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-id: 20200313082444.2439-4-mark.cave-ayland@ilande.co.uk Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-16ide/via: Get rid of via_ide_init()BALATON Zoltan
Follow example of CMD646 and remove via_ide_init function and do it directly in board code instead. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-id: 20200313082444.2439-3-mark.cave-ayland@ilande.co.uk Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-16via-ide: move registration of VMStateDescription to DeviceClassMark Cave-Ayland
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20200313082444.2439-2-mark.cave-ayland@ilande.co.uk Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-16target/riscv: Fix VS mode interrupts forwarding.Rajnesh Kanwal
Currently riscv_cpu_local_irq_pending is used to find out pending interrupt and VS mode interrupts are being shifted to represent S mode interrupts in this function. So when the cause returned by this function is passed to riscv_cpu_do_interrupt to actually forward the interrupt, the VS mode forwarding check does not work as intended and interrupt is actually forwarded to hypervisor. This patch fixes this issue. Signed-off-by: Rajnesh Kanwal <rajnesh.kanwal49@gmail.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-03-16gitlab-ci.yml: Add jobs to build OpenSBI firmware binariesBin Meng
Add two GitLab jobs to build the OpenSBI firmware binaries. The first job builds a Docker image with the packages requisite to build OpenSBI, and stores this image in the GitLab registry. The second job pulls the image from the registry and builds the OpenSBI firmware binaries. The docker image is only rebuilt if the GitLab YAML or the Dockerfile is updated. The second job is only built when the roms/opensbi/ submodule is updated, when a git-ref starts with 'opensbi' or when the last commit contains 'OpenSBI'. The files generated are archived in the artifacts.zip file. With OpenSBI v0.6, it took 2 minutes 56 seconds to build the docker image, and 1 minute 24 seconds to generate the artifacts.zip with the firmware binaries (filesize: 111KiB). See: https://gitlab.com/lbmeng/qemu/pipelines/120520138 Suggested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-03-16riscv: sifive_u: Update BIOS_FILENAME for 32-bitBin Meng
Update BIOS_FILENAME to consider 32-bit bios image file name. Tested booting Linux v5.5 32-bit image (built from rv32_defconfig plus CONFIG_SOC_SIFIVE) with the default 32-bit bios image. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-03-16roms: opensbi: Add 32-bit firmware image for sifive_u machineBin Meng
Although the real world SiFive HiFive Unleashed board is a 64-bit hardware configuration, with QEMU it is possible to test 32-bit configuration with the same hardware features. This updates the roms Makefile to add the build rules for creating the 32-bit OpenSBI firmware image for sifive_u machine. A pre-built OpenSBI v0.6 image has been added as the default bios for 32-bit sifive_u machine. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-03-16roms: opensbi: Upgrade from v0.5 to v0.6Bin Meng
Upgrade OpenSBI from v0.5 to v0.6 and the pre-built bios images. The v0.6 release includes the following commits: dd8ef28 firmware: Fix compile error for FW_PAYLOAD with latest GCC binutils 98f4a20 firmware: Introduce relocation lottery f728a0b include: Sync-up encoding with priv v1.12-draft and hypervisor v0.5-draft 18897aa include: Use _UL() and _ULL() for defines in riscv_encoding.h 7a13beb firmware: Add preferred boot HART field in struct fw_dynamic_info 215421c lib: Remove date and time from init message 838657c include: Remove ilen member of struct unpriv_trap b1d8c98 lib: No need to set VSSTATUS.MXR bit in get_insn() 0e1322b lib: Better naming of unpriv APIs for wider use 75f903d lib: Simplify trap parameters in sbi_ecall functions c96cc03 lib: Fix CPU capabilities detection function ab14f94 lib: Fix probe extension 813f7f4 lib: Add error detection for misa_extension dc40042 include: sbi_platform: fix compilation for GCC-9 bd732ae include: Add guest external interrupt related defines 6590a7d lib: Delegate guest page faults to HS-mode 4370f18 include: Extend struct sbi_trap_info for mtval2 and mtinst 086dbdf lib: Fix sbi_get_insn() for load guest page fault 2be424b lib: Extend trap redirection for hypervisor v0.5 spec 7219477 lib: Use MTINST CSR in misaligned load/store emulation b8732fe lib: Add replacement extension and function ids aa0ed1d lib: Remove redundant IPI types 1092663 lib: Add TIME extension in SBI 9777aee lib: Add IPI extension in SBI 9407202 lib: Add hfence instruction encoding 331ff6a lib: Support stage1 and stage2 tlb flushing 86a31f5 lib: Implement RFENCE extension c7d1b12 firmware: Return real DTB address when FW_xyz_FDT_ADDR is not defined 9beb573 firmware: Improve comments for fw_prev_arg1() and fw_next_arg1() fc6bd90 docs: Improve docs for FDT address passing 46a90d9 lib: utils: Support CLINT with 32bit MMIO access on RV64 system c0849cd platform: Add T-head C910 initial support e746673 lib: Remove unnecessary checks from init_coldboot() and init_warmboot() c3e406f lib: Add initial sbi_exit() API 55e191e lib: Add system early_exit and final_exit APIs 6469ed1 lib: Add timer exit API b325f6b lib: Add ipi exit API 1993182 lib: Add irqchip exit API 2aa43a1 lib: save/restore MIE CSR in sbi_hart_wait_for_coldboot() b0c9787 lib: do sbi_exit() upon halt IPI 15ed1e7 lib: improve system reboot and shutdown implementation 73c19e6 lib: zero-out memory allocated using sbi_scratch_alloc_offset() a67fd68 lib: Add sbi_init_count() API 049ad0b build: Use -ffreestanding e340bbf include: Add OPENSBI_EXTERNAL_SBI_TYPES in sbi_types.h b28b8ac docs: Add description of using OPENSBI_EXTERNAL_SBI_TYPES adf8b73 platform: thead/c910: Remove SBI_PLATFORM_HAS_PMP f95dd39 docs: platform: Update SiFive FU540 doc as-per U-Boot v2020.01 6ffe1be firmware: Fix placement of .align directives 7daccae platform: thead/c910: Don't enable L2 cache in warm boot a73d45c platform: thead/c910: Don't set plic/clint address in warm boot 30cdf00 scripts: Add C910 to platform list in the binary archive script 0492c5d include: Typo fix in comment for SBI_SCRATCH_SIZE define 046cc16 lib: Move struct sbi_ipi_data definition to sbi_ipi.c 3d2aaac lib: Introduce sbi_ipi_send_smode() API da9b76b lib: Introduce sbi_ipi_send_halt() API a8b4b83 lib: Introduce sbi_tlb_fifo_request() API 5f762d1 lib: Introduce sbi_ipi_event_create/destroy() APIs 817d50d lib: Drop _fifo from the name of various sbi_tlb_fifo_xyz() functions 84cd4fc lib: Initialize TLB management directly from coldboot/warmboot path 0a411bf include: Add generic and simple list handling APIs 37923c4 lib: Add dynamic registration of SBI extensions 7668502 lib: Factor-out SBI legacy extension 161b348 lib: Factor-out SBI replacement extensions 43ac621 lib: Factor-out SBI vendor extension 021b9e7 lib: Factor-out SBI base extension 85647a1 platform: template: typo fix in system reboot/shutdown names ac1c229 platform: Update UART base addresses for qemu/sifve_u d79173b platform: Add an platform ops to return platform specific tlb flush limit 2c2bbe7 platform: sifive/fu540: Set tlb range flush limit to zero 5ff1ab0 makefile: add support for building on macOS 6d0b4c5 platform: Drop qemu/sifive_u support 9a717ec platform: sifive: fu540: Add platform specific 'make run' cmd d6fa7f9 doc: sifive: fu540: Update QEMU instruction when using U-Boot as the payload 179edde lib: sbi_scratch: use bitwise ops in sbi_scratch_alloc_offset() 897b8fb lib: Use __builtin_ctzl() in pmp_get() 1a8ca08 lib: Initialize out value in SBI calls c2bfa2b lib: irqchip/plic: Disable all contexts and IRQs c2f23cc platform: Add Spike initial support a062200 platform: Remove stale options from config.mk files c03c8a1 scripts: Add Spike to platform list of binary archive script 29bb2a6 docs: platform: Add documentation for Spike platform 48b06ad ThirdPartyNotices: Fix doc styles 892e879 doc: coreboot: Fix doc styles fdfb533 doc: payload_linux: Fix doc styles 44d1296 doc: andes-ae350: Fix doc styles a8ef0b5 doc: ariane-fpga: Fix doc styles 82fd42f doc: qemu_virt: Fix doc styles f8ce996 doc: sifive_fu540: Fix doc styles 27a5c7f doc: thead-c910: Fix doc styles 0b41453 Revert "lib: Use __builtin_ctzl() in pmp_get()" c66543d lib: utils: htif: Fix 32-bit build bc874e3 lib: Don't check MIDELEG and MEDELEG at end of delegate_traps() 24c3082 lib: Print interrupt and exception delegation in boot prints 66fb729 platform: sifive: fu540: Add 32-bit specific fdt/payload addresses 3e7d666 platform: qemu: virt: Correct the typo in config.mk c3b3b8f lib: Fix typo in atomic exchange functions 3936243 lib: Use available hart mask for correct hbase value f8b3bb8 lib: Simplify the for-loop in sbi_ipi_send_many() ac5e821 include: Bump-up version to 0.6 Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-03-16target/riscv: Correctly implement TSR trapAlistair Francis
As reported in: https://bugs.launchpad.net/qemu/+bug/1851939 we weren't correctly handling illegal instructions based on the value of MSTATUS_TSR and the current privledge level. This patch fixes the issue raised in the bug by raising an illegal instruction if TSR is set and we are in S-Mode. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Jonathan Behrens <jonathan@fintelia.io Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-03-17spapr: Don't clamp RMA to 16GiB on new machine typesDavid Gibson
In spapr_machine_init() we clamp the size of the RMA to 16GiB and the comment saying why doesn't make a whole lot of sense. In fact, this was done because the real mode handling code elsewhere limited the RMA in TCG mode to the maximum value configurable in LPCR[RMLS], 16GiB. But, * Actually LPCR[RMLS] has been able to encode a 256GiB size for a very long time, we just didn't implement it properly in the softmmu * LPCR[RMLS] shouldn't really be relevant anyway, it only was because we used to abuse the RMOR based translation mode in order to handle the fact that we're not modelling the hypervisor parts of the cpu We've now removed those limitations in the modelling so the 16GiB clamp no longer serves a function. However, we can't just remove the limit universally: that would break migration to earlier qemu versions, where the 16GiB RMLS limit still applies, no matter how bad the reasons for it are. So, we replace the 16GiB clamp, with a clamp to a limit defined in the machine type class. We set it to 16 GiB for machine types 4.2 and earlier, but set it to 0 meaning unlimited for the new 5.0 machine type. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17spapr: Don't attempt to clamp RMA to VRMA constraintDavid Gibson
The Real Mode Area (RMA) is the part of memory which a guest can access when in real (MMU off) mode. Of course, for a guest under KVM, the MMU isn't really turned off, it's just in a special translation mode - Virtual Real Mode Area (VRMA) - which looks like real mode in guest mode. The mechanics of how this works when using the hash MMU (HPT) put a constraint on the size of the RMA, which depends on the size of the HPT. So, the latter part of spapr_setup_hpt_and_vrma() clamps the RMA we advertise to the guest based on this VRMA limit. There are several things wrong with this: 1) spapr_setup_hpt_and_vrma() doesn't actually clamp, it takes the minimum of Node 0 memory size and the VRMA limit. That will *often* work the same as clamping, but there can be other constraints on RMA size which supersede Node 0 memory size. We have real bugs caused by this (currently worked around in the guest kernel) 2) Some callers of spapr_setup_hpt_and_vrma() are in a situation where we're past the point that we can actually advertise an RMA limit to the guest 3) But most fundamentally, the VRMA limit depends on host configuration (page size) which shouldn't be visible to the guest, but this partially exposes it. This can cause problems with migration in certain edge cases, although we will mostly get away with it. In practice, this clamping is almost never applied anyway. With 64kiB pages and the normal rules for sizing of the HPT, the theoretical VRMA limit will be 4x(guest memory size) and so never hit. It will hit with 4kiB pages, where it will be (guest memory size)/4. However all mainstream distro kernels for POWER have used a 64kiB page size for at least 10 years. So, simply replace this logic with a check that the RMA we've calculated based only on guest visible configuration will fit within the host implied VRMA limit. This can break if running HPT guests on a host kernel with 4kiB page size. As noted that's very rare. There also exist several possible workarounds: * Change the host kernel to use 64kiB pages * Use radix MMU (RPT) guests instead of HPT * Use 64kiB hugepages on the host to back guest memory * Increase the guest memory size so that the RMA hits one of the fixed limits before the RMA limit. This is relatively easy on POWER8 which has a 16GiB limit, harder on POWER9 which has a 1TiB limit. * Use a guest NUMA configuration which artificially constrains the RMA within the VRMA limit (the RMA must always fit within Node 0). Previously, on KVM, we also temporarily reduced the rma_size to 256M so that the we'd load the kernel and initrd safely, regardless of the VRMA limit. This was a) confusing, b) could significantly limit the size of images we could load and c) introduced a behavioural difference between KVM and TCG. So we remove that as well. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Greg Kurz <groug@kaod.org>
2020-03-17spapr,ppc: Simplify signature of kvmppc_rma_size()David Gibson
This function calculates the maximum size of the RMA as implied by the host's page size of structure of the VRMA (there are a number of other constraints on the RMA size which will supersede this one in many circumstances). The current interface takes the current RMA size estimate, and clamps it to the VRMA derived size. The only current caller passes in an arguably wrong value (it will match the current RMA estimate in some but not all cases). We want to fix that, but for now just keep concerns separated by having the KVM helper function just return the VRMA derived limit, and let the caller combine it with other constraints. We call the new function kvmppc_vrma_limit() to more clearly indicate its limited responsibility. The helper should only ever be called in the KVM enabled case, so replace its !CONFIG_KVM stub with an assert() rather than a dummy value. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cedric Le Goater <clg@fr.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17spapr: Don't use weird units for MIN_RMA_SLOFDavid Gibson
MIN_RMA_SLOF records the minimum about of RMA that the SLOF firmware requires. It lets us give a meaningful error if the RMA ends up too small, rather than just letting SLOF crash. It's currently stored as a number of megabytes, which is strange for global constants. Move that megabyte scaling into the definition of the constant like most other things use. Change from M to MiB in the associated message while we're at it. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17target/ppc: Don't store VRMA SLBE persistentlyDavid Gibson
Currently, we construct the SLBE used for VRMA translations when the LPCR is written (which controls some bits in the SLBE), then use it later for translations. This is a bit complex and confusing - simplify it by simply constructing the SLBE directly from the LPCR when we need it. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17target/ppc: Only calculate RMLS derived RMA limit on demandDavid Gibson
When the LPCR is written, we update the env->rmls field with the RMA limit it implies. Simplify things by just calculating the value directly from the LPCR value when we need it. It's possible this is a little slower, but it's unlikely to be significant, since this is only for real mode accesses in a translation configuration that's not used very often, and the whole thing is behind the qemu TLB anyway. Therefore, keeping the number of state variables down and not having to worry about making sure it's always in sync seems the better option. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17target/ppc: Correct RMLS tableDavid Gibson
The table of RMA limits based on the LPCR[RMLS] field is slightly wrong. We're missing the RMLS == 0 => 256 GiB RMA option, which is available on POWER8, so add that. The comment that goes with the table is much more wrong. We *don't* filter invalid RMLS values when writing the LPCR, and there's not really a sensible way to do so. Furthermore, while in theory the set of RMLS values is implementation dependent, it seems in practice the same set has been available since around POWER4+ up until POWER8, the last model which supports RMLS at all. So, correct that as well. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2020-03-17target/ppc: Streamline calculation of RMA limit from LPCR[RMLS]David Gibson
Currently we use a big switch statement in ppc_hash64_update_rmls() to work out what the right RMA limit is based on the LPCR[RMLS] field. There's no formula for this - it's just an arbitrary mapping defined by the existing CPU implementations - but we can make it a bit more readable by using a lookup table rather than a switch. In addition we can use the MiB/GiB symbols to make it a bit clearer. While there we add a bit of clarity and rationale to the comment about what happens if the LPCR[RMLS] doesn't contain a valid value. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17target/ppc: Use class fields to simplify LPCR maskingDavid Gibson
When we store the Logical Partitioning Control Register (LPCR) we have a big switch statement to work out which are valid bits for the cpu model we're emulating. As well as being ugly, this isn't really conceptually correct, since it is based on the mmu_model variable, whereas the LPCR isn't (only) about the MMU, so mmu_model is basically just acting as a proxy for the cpu model. Handle this in a simpler way, by adding a suitable lpcr_mask to the QOM class. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17target/ppc: Remove RMOR register from POWER9 & POWER10David Gibson
Currently we create the Real Mode Offset Register (RMOR) on all Book3S cpus from POWER7 onwards. However the translation mode which the RMOR controls is no longer supported in POWER9, and so the register has been removed from the architecture. Remove it from our model on POWER9 and POWER10. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2020-03-17spapr, ppc: Remove VPM0/RMLS hacks for POWER9David Gibson
For the "pseries" machine, we use "virtual hypervisor" mode where we only model the CPU in non-hypervisor privileged mode. This means that we need guest physical addresses within the modelled cpu to be treated as absolute physical addresses. We used to do that by clearing LPCR[VPM0] and setting LPCR[RMLS] to a high limit so that the old offset based translation for guest mode applied, which does what we need. However, POWER9 has removed support for that translation mode, which meant we had some ugly hacks to keep it working. We now explicitly handle this sort of translation for virtual hypervisor mode, so the hacks aren't necessary. We don't need to set VPM0 and RMLS from the machine type code - they're now ignored in vhyp mode. On the cpu side we don't need to allow LPCR[RMLS] to be set on POWER9 in vhyp mode - that was only there to allow the hack on the machine side. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2020-03-17target/ppc: Introduce ppc_hash64_use_vrma() helperDavid Gibson
When running guests under a hypervisor, the hypervisor obviously needs to be protected from guest accesses even if those are in what the guest considers real mode (translation off). The POWER hardware provides two ways of doing that: The old way has guest real mode accesses simply offset and bounds checked into host addresses. It works, but requires that a significant chunk of the guest's memory - the RMA - be physically contiguous in the host, which is pretty inconvenient. The new way, known as VRMA, has guest real mode accesses translated in roughly the normal way but with some special parameters. In POWER7 and POWER8 the LPCR[VPM0] bit selected between the two modes, but in POWER9 only VRMA mode is supported and LPCR[VPM0] no longer exists. We handle that difference in behaviour in ppc_hash64_set_isi().. but not in other places that we blindly check LPCR[VPM0]. Correct those instances with a new helper to tell if we should be in VRMA mode. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17target/ppc: Correct handling of real mode accesses with vhyp on hash MMUDavid Gibson
On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we only model the non-hypervisor-privileged parts of the cpu. Essentially we model the hypervisor's behaviour from the point of view of a guest OS, but we don't model the hypervisor's execution. In particular, in this mode, qemu's notion of target physical address is a guest physical address from the vcpu's point of view. So accesses in guest real mode don't require translation. If we were modelling the hypervisor mode, we'd need to translate the guest physical address into a host physical address. Currently, we handle this sloppily: we rely on setting up the virtual LPCR and RMOR registers so that GPAs are simply HPAs plus an offset, which we set to zero. This is already conceptually dubious, since the LPCR and RMOR registers don't exist in the non-hypervisor portion of the CPU. It gets worse with POWER9, where RMOR and LPCR[VPM0] no longer exist at all. Clean this up by explicitly handling the vhyp case. While we're there, remove some unnecessary nesting of if statements that made the logic to select the correct real mode behaviour a bit less clear than it could be. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2020-03-17ppc: Remove stub of PPC970 HID4 implementationDavid Gibson
The PowerPC 970 CPU was a cut-down POWER4, which had hypervisor capability. However, it can be (and often was) strapped into "Apple mode", where the hypervisor capabilities were disabled (essentially putting it always in hypervisor mode). That's actually the only mode of the 970 we support in qemu, and we're unlikely to change that any time soon. However, we do have a partial implementation of the 970's HID4 register which affects things only relevant for hypervisor mode. That stub is also really ugly, since it attempts to duplicate the effects of HID4 by re-encoding it into the LPCR register used in newer CPUs, but in a really confusing way. Just get rid of it. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2020-03-17ppc: Remove stub support for 32-bit hypervisor modeDavid Gibson
a4f30719a8cd, way back in 2007 noted that "PowerPC hypervisor mode is not fundamentally available only for PowerPC 64" and added a 32-bit version of the MSR[HV] bit. But nothing was ever really done with that; there is no meaningful support for 32-bit hypervisor mode 13 years later. Let's stop pretending and just remove the stubs. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17hw/ppc/pnv: Fix typo in commentPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200228123303.14540-1-philmd@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17spapr: Fix Coverity warning while validating nvdimm optionsShivaprasad G Bhat
Fixes Coverity issue, CID 1419883: Error handling issues (CHECKED_RETURN) Calling "qemu_uuid_parse" without checking return value nvdimm_set_uuid() already verifies if the user provided uuid is valid or not. So, need to check for the validity during pre-plug validation again. As this a false positive in this case, assert if not valid to be safe. Also, error_abort if QOM accessor encounters error while fetching the uuid property. Reported-by: Coverity (CID 1419883) Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Message-Id: <158281096564.89540.4507375445765515529.stgit@lep8c.aus.stglabs.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17ppc: Officially deprecate the CPU "compat" propertyGreg Kurz
Server class POWER CPUs have a "compat" property, which was obsoleted by commit 7843c0d60d and replaced by a "max-cpu-compat" property on the pseries machine type. A hack was introduced so that passing "compat" to -cpu would still produce the desired effect, for the sake of backward compatibility : it strips the "compat" option from the CPU properties and applies internally it to the pseries machine. The accessors of the "compat" property were updated to do nothing but warn the user about the deprecated status when doing something like: $ qemu-system-ppc64 -global POWER9-family-powerpc64-cpu.compat=power9 qemu-system-ppc64: warning: CPU 'compat' property is deprecated and has no effect; use max-cpu-compat machine property instead This was merged during the QEMU 2.10 timeframe, a few weeks before we formalized our deprecation process. As a consequence, the "compat" property fell through the cracks and was never listed in the officialy deprecated features. We are now eight QEMU versions later, it is largely time to mention it in qemu-deprecated.texi. Also, since -global XXX-powerpc64-cpu.compat= has been emitting warnings since QEMU 2.10 and the usual way of setting CPU properties is with -cpu, completely remove the "compat" property. Keep the hack so that -cpu XXX,compat= stays functional some more time, as required by our deprecation process. The now empty powerpc_servercpu_properties[] list which was introduced for "compat" and never had any other use is removed on the way. We can re-add it in the future if the need for a server class POWER CPU specific property arises again. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <158274357799.140275.12263135811731647490.stgit@bahia.lan> [dwg: Convert from .texi to .rst to match upstream change] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17spapr: Handle pending hot plug/unplug requests at CASGreg Kurz
If a hot plug or unplug request is pending at CAS, we currently trigger a CAS reboot, which severely increases the guest boot time. This is because SLOF doesn't handle hot plug events and we had no way to fix the FDT that gets presented to the guest. We can do better thanks to recent changes in QEMU and SLOF: - we now return a full FDT to SLOF during CAS - SLOF was fixed to correctly detect any device that was either added or removed since boot time and to update its internal DT accordingly. The right solution is to process all pending hot plug/unplug requests during CAS: convert hot plugged devices to cold plugged devices and remove the hot unplugged ones, which is exactly what spapr_drc_reset() does. Also clear all hot plug events that are currently queued since they're no longer relevant. Note that SLOF cannot currently populate hot plugged PCI bridges or PHBs at CAS. Until this limitation is lifted, SLOF will reset the machine when this scenario occurs : this will allow the FDT to be fully processed when SLOF is started again (ie. the same effect as the CAS reboot that would occur anyway without this patch). Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <158257222352.4102917.8984214333937947307.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17pseries: Update SLOF firmware imageAlexey Kardashevskiy
This adds vTPM support, full-FDT-rebuild-on-CAS fixes and basic ext4 support. The full changelog is: Alexey Kardashevskiy (10): disk-label: Prepare for extenting disk-label: Support Linux GPT partition type ext2: Prepare for extending ext2: Rename group-desc-size ext2: Read size of group descriptors ext2: Read all 64bit of inode number ext2/4: Add basic extent tree support elf64: Add LE64 ABIv1/2 support for loading images to given address fdt: Fix creating new nodes at H_CAS version: update to 20200221 Greg Kurz (2): fdt: Fix update of "interrupt-controller" node at CAS fdt: Delete nodes of devices removed between boot and CAS Stefan Berger (8): slof: Implement SLOF_get_keystroke() and SLOF_reset() slof: Make linker script variables accessible qemu: Make print_version variable accessible tpm: Add TPM CRQ driver implementation tpm: Add sha256 implementation tcgbios: Add TPM 2.0 support and firmware API tcgbios: Implement menu to clear TPM 2 and activate its PCR banks tcgbios: Measure the GPT table Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-16cpus: avoid pause_all_vcpus getting stuck due to raceLongpeng
We found an issue when repeat reboot in guest during migration, it cause the migration thread never be waken up again. <main loop> |<migration_thread> | LOCK BQL | ... | main_loop_should_exit | pause_all_vcpus | 1. set all cpus ->stop=true | and then kick | 2. return if all cpus is paused | (by '->stopped == true'), else| 3. qemu_cond_wait [BQL UNLOCK] | |LOCK BQL |... |do_vm_stop | pause_all_vcpus | (A)set all cpus ->stop=true | and then kick | (B)return if all cpus is paused | (by '->stopped == true'), else | (C)qemu_cond_wait [BQL UNLOCK] 4. be waken up and LOCK BQL | (D)be waken up BUT wait for BQL 5. goto 2. | (BQL is still LOCKed) | resume_all_vcpus | 1. set all cpus ->stop=false | and ->stopped=false | ... | BQL UNLOCK | (E)LOCK BQL | (F)goto B. [but stopped is false now!] |Finally, sleep at step 3 forever. resume_all_vcpus should notice this race, so we need to move the change of runstate before pause_all_vcpus in do_vm_stop() and ignore the resume request if runstate is not running. Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Signed-off-by: Longpeng <longpeng2@huawei.com> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200316083732.2010-1-longpeng2@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16exec/rom_reset: Free rom data during inmigrate skipDr. David Alan Gilbert
Commit 355477f8c73e9 skips rom reset when we're an incoming migration so as not to overwrite shared ram in the ignore-shared migration optimisation. However, it's got an unexpected side effect that because it skips freeing the ROM data, when rom_reset gets called later on, after migration (e.g. during a reboot), the ROM does get reset to the original file contents. Because of seabios/x86's weird reboot process this confuses a reboot into hanging after a migration. Fixes: 355477f8c73e9 ("migration: do not rom_reset() during incoming migration") https://bugzilla.redhat.com/show_bug.cgi?id=1809380 Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16Use -isystem for linux-headers dirEduardo Habkost
glibc and Linux-provided headers are known to generate macro redefinition warnings when used together. For example: <linux/mman.h> and <sys/mman.h> duplicate some macro definitions. We normally never see those warnings because GCC suppresses warnings generated by system headers. We carry our own copy of Linux header files, though, and this makes those warnings not be suppressed when glibc headers are included before Linux headers (e.g. if <sys/mman.h> is included before <linux/mman.h>). Use -isystem instead of -I for linux-headers. This makes the compiler treat our linux-headers directory the same way it treats system-provided Linux headers, and suppress warnings generated by them. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16softmmu/vl.c: Handle '-cpu help' and '-device help' before 'no default machine'Peter Maydell
Currently if you try to ask for the list of CPUs for a target architecture which does not specify a default machine type you just get an error: $ qemu-system-arm -cpu help qemu-system-arm: No machine specified, and there is no default Use -machine help to list supported machines Since the list of CPUs doesn't depend on the machine, this is unnecessarily unhelpful. "-device help" has a similar problem. Move the checks for "did the user ask for -cpu help or -device help" up so they precede the select_machine() call which checks that the user specified a valid machine type. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16qemu-cpu-models.rst: Document -noTSX, mds-no, taa-no, and tsx-ctrlKashyap Chamarthy
- Add the '-noTSX' variants for CascadeLake and SkyLake. - Document the three MSR bits: 'mds-no', 'taa-no', and 'tsx-ctrl' Two confusing things about 'mds-no' (and the first point applies to the other two MSRs too): (1) The 'mds-no' bit will _not_ show up in the guest's /proc/cpuinfo. Rather it is used to fill in the guest's sysfs: /sys/devices/system/cpu/vulnerabilities/mds:Not affected Paolo confirmed on IRC as such. (2) There are _three_ variants[+] of CascadeLake CPUs, with different stepping levels: 5, 6, and 7. To quote wikichip.org[*]: "note that while steppings 6 & 7 are fully mitigated, earlier stepping 5 is not protected against MSBDS, MLPDS, nor MDSUM" The above is also indicated in the Intel's document[+], as indicated by "No" under the three columns of MFBDS, MSBDS, and MLPDS. I've expressed this in the docs without belabouring the details. [+] https://software.intel.com/security-software-guidance/insights/processors-affected-microarchitectural-data-sampling [*] https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#Key_changes_from_Skylake Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> Message-Id: <20200225165618.6571-3-kchamart@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16ui/curses: Move arrays to .heap to save 74KiB of .bssPhilippe Mathieu-Daudé
We only need these arrays when using the curses display. Move them from the .bss to the .heap (sizes reported on x86_64 host: screen[] is 64KiB, vga_to_curses 7KiB). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16ui/curses: Make control_characters[] array constPhilippe Mathieu-Daudé
As we only use this array as input, make it const. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16hw/usb/quirks: Use smaller types to reduce .rodata by 10KiBPhilippe Mathieu-Daudé
The USB descriptor sizes are specified as 16-bit for idVendor / idProduct, and 8-bit for bInterfaceClass / bInterfaceSubClass / bInterfaceProtocol. Doing so we reduce the usbredir_raw_serial_ids[] and usbredir_ftdi_serial_ids[] arrays from 16KiB to 6KiB (size reported on x86_64 host, building with --extra-cflags=-Os). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16hw/audio/intel-hda: Use memory region alias to reduce .rodata by 4.34MBPhilippe Mathieu-Daudé
The intel-hda model uses an array of register indexed by the register address. This array also contains a pair of aliased registers at offset 0x2000. This creates a huge hole in the array, which ends up eating 4.6MiB of .rodata (size reported on x86_64 host, building with --extra-cflags=-Os). By using a memory region alias, we reduce this array to 132kB. Before: (qemu) info mtree 00000000febd4000-00000000febd7fff (prio 1, i/o): intel-hda After: (qemu) info mtree 00000000febd4000-00000000febd7fff (prio 1, i/o): intel-hda 00000000febd4000-00000000febd7fff (prio 1, i/o): intel-hda-container 00000000febd4000-00000000febd5fff (prio 0, i/o): intel-hda 00000000febd6000-00000000febd7fff (prio 0, i/o): alias intel-hda-alias @intel-hda 0000000000000000-0000000000001fff Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16hw/audio/fmopl: Move ENV_CURVE to .heap to save 32KiB of .bssPhilippe Mathieu-Daudé
This buffer is only used by the adlib audio device. Move it to the .heap to release 32KiB of .bss (size reported on x86_64 host). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16Makefile: Let the 'help' target list the tools targetsPhilippe Mathieu-Daudé
List the name of the tool targets when calling 'make help': $ make help [...] Tools targets: qemu-ga - Build qemu-ga tool qemu-keymap - Build qemu-keymap tool elf2dmp - Build elf2dmp tool ivshmem-client - Build ivshmem-client tool ivshmem-server - Build ivshmem-server tool qemu-nbd - Build qemu-nbd tool qemu-img - Build qemu-img tool qemu-io - Build qemu-io tool qemu-edid - Build qemu-edid tool fsdev/virtfs-proxy-helper - Build virtfs-proxy-helper tool scsi/qemu-pr-helper - Build qemu-pr-helper tool Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16Makefile: Align 'help' target outputPhilippe Mathieu-Daudé
The 'help' target is displayed unaligned. Add a print-help function and use it. Now if someone want to change the indentation, there is a single place to modify. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16WHPX: Use proper synchronization primitives while processingSunil Muthuswamy
WHPX wasn't using the proper synchronization primitives while processing async events, which can cause issues with SMP. Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16i386: Fix GCC warning with snprintf when HAX is enabledJulio Faracco
When HAX is enabled (--enable-hax), GCC 9.2.1 reports issues with snprintf(). Replacing old snprintf() by g_strdup_printf() fixes the problem with boundary checks of vm_id and vcpu_id and finally the warnings produced by GCC. For more details, one example of warning: CC i386-softmmu/target/i386/hax-posix.o qemu/target/i386/hax-posix.c: In function ‘hax_host_open_vm’: qemu/target/i386/hax-posix.c:124:56: error: ‘%02d’ directive output may be truncated writing between 2 and 11 bytes into a region of size 3 [-Werror=format-truncation=] 124 | snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%02d", vm_id); | ^~~~ qemu/target/i386/hax-posix.c:124:41: note: directive argument in the range [-2147483648, 64] 124 | snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%02d", vm_id); | ^~~~~~~~~~~~~~~~~~~~ In file included from /usr/include/stdio.h:867, from qemu/include/qemu/osdep.h:99, from qemu/target/i386/hax-posix.c:14: /usr/include/bits/stdio2.h:67:10: note: ‘__builtin___snprintf_chk’ output between 17 and 26 bytes into a destination of size 17 67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 68 | __bos (__s), __fmt, __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Julio Faracco <jcfaracco@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16qom/object: Use common get/set uint helpersFelipe Franciosi
Several objects implemented their own uint property getters and setters, despite them being straightforward (without any checks/validations on the values themselves) and identical across objects. This makes use of an enhanced API for object_property_add_uintXX_ptr() which offers default setters. Some of these setters used to update the value even if the type visit failed (eg. because the value being set overflowed over the given type). The new setter introduces a check for these errors, not updating the value if an error occurred. The error is propagated. Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16ich9: Simplify ich9_lpc_initfnFelipe Franciosi
Currently, ich9_lpc_initfn simply serves as a caller to ich9_lpc_add_properties. This simplifies the code a bit by eliminating ich9_lpc_add_properties altogether and executing its logic in the parent object initialiser function. Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16ich9: fix getter type for sci_int propertyFelipe Franciosi
When QOM APIs were added to ich9 in 6f1426ab, the getter for sci_int was written using uint32_t. However, the object property is uint8_t. This fixes the getter for correctness. Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16qom/object: enable setter for uint typesFelipe Franciosi
Traditionally, the uint-specific property helpers only offer getters. When adding object (or class) uint types, one must therefore use the generic property helper if a setter is needed (and probably duplicate some code writing their own getters/setters). This enhances the uint-specific property helper APIs by adding a bitwise-or'd 'flags' field and modifying all clients of that API to set this paramater to OBJ_PROP_FLAG_READ. This maintains the current behaviour whilst allowing others to also set OBJ_PROP_FLAG_WRITE (or use the more convenient OBJ_PROP_FLAG_READWRITE) in the future (which will automatically install a setter). Other flags may be added later. Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16memory: Fix start offset for bitmap log_clear hookMatt Borgerson
Currently only the final page offset is being passed to the `log_clear` hook via `memory_region_clear_dirty_bitmap` after it is used as an iterator in `cpu_physical_memory_test_and_clear_dirty`. This patch corrects the start address and size of the region. Signed-off-by: Matt Borgerson <contact@mborgerson.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16tests/docker: Install SASL library to extend code coverage on amd64Philippe Mathieu-Daudé
Install the SASL library to build the VNC SASL auth protocol code. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200309122454.22551-3-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>