aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-03-29spapr: Simplify handling of host-serial and host-model valuesDavid Gibson2-38/+20
27461d69a0f "ppc: add host-serial and host-model machine attributes (CVE-2019-8934)" introduced 'host-serial' and 'host-model' machine properties for spapr to explicitly control the values advertised to the guest in device tree properties with the same names. The previous behaviour on KVM was to unconditionally populate the device tree with the real host serial number and model, which leaks possibly sensitive information about the host to the guest. To maintain compatibility for old machine types, we allowed those props to be set to "passthrough" to take the value from the host as before. Or they could be set to "none" to explicitly omit the device tree items. Special casing specific values on what's otherwise a user supplied string is very ugly. So, this patch simplifies things by implementing the backwards compatibility in a different way: we have a machine class flag set for the older machines, and we only load the host values into the device tree if A) they're not set by the user and B) we have that flag set. This does mean that the "passthrough" functionality is no longer available with the current machine type. That's ok though: if a user or management layer really wants the information passed through they can read it themselves (OpenStack Nova already does something similar for x86). It also means the user can't explicitly ask for the values to be omitted on the old machine types. I think that's an acceptable trade-off: if you care enough about not leaking the host information you can either move to the new machine type, or use a dummy value for the properties. For the new machine type, this also removes an odd inconsistency between running on a POWER and non-POWER (or non-Linux) hosts: if the host information couldn't be read from where we expect (in the host's device tree as exposed by Linux), we'd fallback to omitting the guest device tree items. While we're there, improve some poorly worded comments, and the help text for the properties. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Greg Kurz <groug@kaod.org>
2019-03-29target/ppc: Fix QEMU crash with stxsdxGreg Kurz1-1/+1
I've been hitting several QEMU crashes while running a fedora29 ppc64le guest under TCG. Each time, this would occur several minutes after the guest reached login: Fedora 29 (Twenty Nine) Kernel 4.20.6-200.fc29.ppc64le on an ppc64le (hvc0) Web console: https://localhost:9090/ localhost login: tcg/tcg.c:3211: tcg fatal error This happens because a bug crept up in the gen_stxsdx() helper when it was converted to use VSR register accessors by commit 8b3b2d75c7c04 "target/ppc: introduce get_cpu_vsr{l,h}() and set_cpu_vsr{l,h}() helpers for VSR register access". The code creates a temporary, passes it directly to gen_qemu_st64_i64() and then to set_cpu_vrsh()... which looks like this was mistakenly coded as a load instead of a store. Reverse the logic: read the VSR to the temporary first and then store it to memory. Fixes: 8b3b2d75c7c0481544e277dad226223245e058eb Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155371035249.2038502.12364252604337688538.stgit@bahia.lan> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-29target/ppc: Improve comment of bcctr used for spectre v2 mitigationGreg Kurz1-1/+9
Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155359567174.1794128.3183997593369465355.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-29target/ppc: Consolidate 64-bit server processor detection in a helperGreg Kurz4-8/+12
We use PPC_SEGMENT_64B in various places to guard code that is specific to 64-bit server processors compliant with arch 2.x. Consolidate the logic in a helper macro with an explicit name. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155327783157.1283071.3747129891004927299.stgit@bahia.lan> Tested-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-29target/ppc: Enable "decrement and test CTR" version of bcctrGreg Kurz1-15/+37
Even if all ISAs up to v3 indeed mention: If the "decrement and test CTR" option is specified (BO2=0), the instruction form is invalid. The UMs of all existing 64-bit server class processors say: If BO[2] = 0, the contents of CTR (before any update) are used as the target address and for the test of the contents of CTR to resolve the branch. The contents of the CTR are then decremented and written back to the CTR. The linux kernel has spectre v2 mitigation code that relies on a BO[2] = 0 variant of bcctr, which is now activated by default on spapr, even with TCG. This causes linux guests to panic with the default machine type under TCG. Since any CPU model can provide its own behaviour for invalid forms, we could possibly introduce a new instruction flag to handle this. In practice, since the behaviour is shared by all 64-bit server processors starting with 970 up to POWER9, let's reuse the PPC_SEGMENT_64B flag. Caveat: this may have to be fixed later if POWER10 introduces a different behaviour. The existing behaviour of throwing a program interrupt is kept for all other CPU models. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155327782604.1283071.10640596307206921951.stgit@bahia.lan> Tested-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-29target/ppc: Fix TCG temporary leaks in gen_bcond()Greg Kurz1-0/+2
Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155327782047.1283071.10234727692461848972.stgit@bahia.lan> Tested-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-28Merge remote-tracking branch ↵Peter Maydell1-1/+2
'remotes/alistair/tags/pull-device-tree-20190327' into staging Device Tree Pull Request for 4.0 A single patch updating the MAINTAINERS file for 4.0. # gpg: Signature made Wed 27 Mar 2019 17:02:00 GMT # gpg: using RSA key F6C4AC46D4934868D3B8CE8F21E10D29DF977054 # gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [full] # Primary key fingerprint: F6C4 AC46 D493 4868 D3B8 CE8F 21E1 0D29 DF97 7054 * remotes/alistair/tags/pull-device-tree-20190327: MAINTAINERS: Update the device tree maintainers Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-28Merge remote-tracking branch 'remotes/otubo/tags/pull-seccomp-20190327' into ↵Peter Maydell1-14/+38
staging pull-seccomp-20190327 # gpg: Signature made Wed 27 Mar 2019 12:12:39 GMT # gpg: using RSA key DF32E7C0F0FFF9A2 # gpg: Good signature from "Eduardo Otubo (Senior Software Engineer) <otubo@redhat.com>" [full] # Primary key fingerprint: D67E 1B50 9374 86B4 0723 DBAB DF32 E7C0 F0FF F9A2 * remotes/otubo/tags/pull-seccomp-20190327: seccomp: report more useful errors from seccomp seccomp: don't kill process for resource control syscalls Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-28Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell34-134/+172
* Kconfig improvements (msi_nonbroken, imply for default PCI devices) * intel-iommu: sharing passthrough FlatViews (Peter) * Fix for SEV with VFIO (Brijesh) * Allow compilation without CONFIG_PARALLEL (Thomas) # gpg: Signature made Thu 21 Mar 2019 16:42:24 GMT # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (23 commits) virtio-vga: only enable for specific boards config-all-devices.mak: rebuild on reconfigure minikconf: fix parser typo intel-iommu: optimize nodmar memory regions test-announce-self: convert to qgraph hw/alpha/Kconfig: DP264 hardware requires e1000 network card hw/hppa/Kconfig: Dino board requires e1000 network card hw/sh4/Kconfig: r2d machine requires the rtl8139 network card hw/ppc/Kconfig: e500 based machines require virtio-net-pci device hw/ppc/Kconfig: Bamboo machine requires e1000 network card hw/mips/Kconfig: Fulong 2e board requires ati-vga/rtl8139 PCI devices hw/mips/Kconfig: Malta machine requires the pcnet network card hw/i386/Kconfig: enable devices that can be created by default hw/isa/Kconfig: PIIX4 southbridge requires USB UHCI hw/isa/Kconfig: i82378 SuperIO requires PC speaker device prep: do not select I82374 hw/i386/Kconfig: PC uses I8257, not I82374 hw/char/parallel: Make it possible to compile also without CONFIG_PARALLEL target/i386: sev: Do not pin the ram device memory region memory: Fix the memory region type assignment order ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org> # Conflicts: # hw/rdma/Makefile.objs # hw/riscv/sifive_plic.c
2019-03-28Merge remote-tracking branch 'remotes/xtensa/tags/20190326-xtensa' into stagingPeter Maydell6-169/+18
target/xtensa fixes for v4.0: - fix translation of FLIX bundles with multiple references to the same register; - don't announce exit simcall; - clean up tests/tcg/xtensa. # gpg: Signature made Tue 26 Mar 2019 17:58:59 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/20190326-xtensa: tests/tcg/xtensa: clean up test set target/xtensa: don't announce exit simcall target/xtensa: fix break_dependency for repeated resources Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-27MAINTAINERS: Update the device tree maintainersAlistair Francis1-1/+2
Remove Alex as a Device Tree maintainer as requested by him. Add myself as a maintainer to avoid it being orphaned. Also add David as a Reviewer (R) as he is the libfdt and DTC maintainer. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alexander Graf <agraf@csgraf.de> Acked-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-27seccomp: report more useful errors from seccompDaniel P. Berrangé1-7/+13
Most of the seccomp functions return errnos as a negative return value. The code is currently ignoring these and reporting a generic error message for all seccomp failure scenarios making debugging painful. Report a more precise error from each failed call and include errno if it is available. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Eduardo Otubo <otubo@redhat.com>
2019-03-27seccomp: don't kill process for resource control syscallsDaniel P. Berrangé1-7/+25
The Mesa library tries to set process affinity on some of its threads in order to optimize its performance. Currently this results in QEMU being immediately terminated when seccomp is enabled. Mesa doesn't consider failure of the process affinity settings to be fatal to its operation, but our seccomp policy gives it no choice in gracefully handling this denial. It is reasonable to consider that malicious code using the resource control syscalls to be a less serious attack than if they were trying to spawn processes or change UIDs and other such things. Generally speaking changing the resource control setting will "merely" affect quality of service of processes on the host. With this in mind, rather than kill the process, we can relax the policy for these syscalls to return the EPERM errno value. This allows callers to detect that QEMU does not want them to change resource allocations, and apply some reasonable fallback logic. The main downside to this is for code which uses these syscalls but does not check the return value, blindly assuming they will always succeeed. Returning an errno could result in sub-optimal behaviour. Arguably though such code is already broken & needs fixing regardless. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Eduardo Otubo <otubo@redhat.com>
2019-03-26Update version for v4.0.0-rc1 releasev4.0.0-rc1Peter Maydell1-1/+1
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-26Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into stagingPeter Maydell13-24/+133
Block layer patches: - Fix slow pre-zeroing in qemu-img convert - Test case for block job pausing on I/O errors # gpg: Signature made Tue 26 Mar 2019 15:28:00 GMT # gpg: using RSA key 7F09B272C88F2FD6 # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full] # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6 * remotes/kevin/tags/for-upstream: qemu-io: Add write -n for BDRV_REQ_NO_FALLBACK qemu-img: Use BDRV_REQ_NO_FALLBACK for pre-zeroing file-posix: Support BDRV_REQ_NO_FALLBACK for zero writes block: Advertise BDRV_REQ_NO_FALLBACK in filter drivers block: Add BDRV_REQ_NO_FALLBACK block: Remove error messages in bdrv_make_zero() iotests: add 248: test resume mirror after auto pause on ENOSPC Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-26Merge remote-tracking branch ↵Peter Maydell2-18/+7
'remotes/kraxel/tags/fixes-20190326-pull-request' into staging fixes for 4.0: ohci and ati-vga # gpg: Signature made Tue 26 Mar 2019 14:05:40 GMT # gpg: using RSA key 4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full] # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [full] # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full] # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/fixes-20190326-pull-request: ati-vga: Fix indexed access to video memory ohci: don't die on ED_LINK_LIMIT overflow Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-26Merge remote-tracking branch ↵Peter Maydell2-2/+17
'remotes/pmaydell/tags/pull-target-arm-20190326' into staging target-arm queue: * Set SIMDMISC and FPMISC for 32-bit -cpu max (fixes regression from 3.1) * fix vCont packet handling when no thread is specified # gpg: Signature made Tue 26 Mar 2019 13:09:48 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-20190326: gdbstub: fix vCont packet handling when no thread is specified target/arm: Set SIMDMISC and FPMISC for 32-bit -cpu max Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-26gdbstub: fix vCont packet handling when no thread is specifiedLuc Michel1-2/+12
The vCont packet accepts a series of actions, each being applied on a given thread ID. Giving no thread ID for an action is valid and means "all threads". This commit fixes vCont packets being incorrectly rejected when no thread ID was given for an action. In multiprocess mode, the GDB Remote Protocol specification is unclear on what "all threads" means. We choose to apply the action on all threads of all attached processes. This commit is based on the initial fix by Lucien Murray-Pitts. Fixes: e40e5204af8388 Reported-by: Lucien Murray-Pitts <lucienmp_antispam@yahoo.com> Reported-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Luc Michel <luc.michel@greensocs.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190325110452.6756-1-luc.michel@greensocs.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-26target/arm: Set SIMDMISC and FPMISC for 32-bit -cpu maxRichard Henderson1-0/+5
Fixes: https://bugs.launchpad.net/bugs/1821430 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20190325161338.6536-1-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-26ati-vga: Fix indexed access to video memoryBALATON Zoltan1-12/+6
Coverity (CID 1399700) found that this was wrong so instead of trying to do it by hand use existing access functions that should work better. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20190318223842.427CB7456B2@zero.eik.bme.hu Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-03-26ohci: don't die on ED_LINK_LIMIT overflowLaurent Vivier1-6/+1
Stop processing the descriptor list instead. The next frame timer tick will resume the work Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1686705 Suggested-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-id: 20190321085212.10796-1-lvivier@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-03-26qemu-io: Add write -n for BDRV_REQ_NO_FALLBACKKevin Wolf1-2/+11
This makes the new BDRV_REQ_NO_FALLBACK flag available in the qemu-io write command. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Acked-by: Eric Blake <eblake@redhat.com>
2019-03-26qemu-img: Use BDRV_REQ_NO_FALLBACK for pre-zeroingKevin Wolf1-1/+1
If qemu-img convert sees that the target image isn't zero-initialised yet, it tries to do an efficient zero write for the whole image first to save the overhead of repeated explicit zero writes during the conversion. Obviously, this provides only an advantage if the pre-zeroing is actually efficient. Otherwise, we can end up writing zeroes slowly while zeroing out the whole image, and then overwrite the same blocks again with real data, potentially doubling the written data. Pass BDRV_REQ_NO_FALLBACK to blk_make_zero() to avoid this case. If we can't efficiently zero out, we'll instead write explicit zeroes only if there is no data to be written to a block. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Acked-by: Eric Blake <eblake@redhat.com>
2019-03-26file-posix: Support BDRV_REQ_NO_FALLBACK for zero writesKevin Wolf2-8/+17
We know that the kernel implements a slow fallback code path for BLKZEROOUT, so if BDRV_REQ_NO_FALLBACK is given, we shouldn't call it. The other operations we call in the context of .bdrv_co_pwrite_zeroes should usually be quick, so no modification should be needed for them. If we ever notice that there are additional problematic cases, we can still make these conditional as well. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Acked-by: Eric Blake <eblake@redhat.com>
2019-03-26block: Advertise BDRV_REQ_NO_FALLBACK in filter driversKevin Wolf4-7/+7
Filter drivers that support .bdrv_co_pwrite_zeroes can safely advertise BDRV_REQ_NO_FALLBACK because they just forward the request flags to their child node. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Acked-by: Eric Blake <eblake@redhat.com>
2019-03-26block: Add BDRV_REQ_NO_FALLBACKKevin Wolf2-2/+17
For qemu-img convert, we want an operation that zeroes out the whole image if this can be done efficiently, but that returns an error otherwise so we don't write explicit zeroes and immediately overwrite them with the real data, potentially doubling the amount of data to be written. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Acked-by: Eric Blake <eblake@redhat.com>
2019-03-26block: Remove error messages in bdrv_make_zero()Kevin Wolf1-4/+0
There is only a single caller of bdrv_make_zero(), which is qemu-img convert. If the function fails, we just fall back to a different method of zeroing out blocks on the target image. There is no good reason to print error messages on stderr when the higher level operation will actually succeed. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Acked-by: Eric Blake <eblake@redhat.com>
2019-03-26iotests: add 248: test resume mirror after auto pause on ENOSPCVladimir Sementsov-Ogievskiy3-0/+80
Test that mirror job actually resume on resume command after being automatically paused on ENOSPC error. It's a follow-up test for 8d9648cbf3e "blockjob: fix user pause in block_job_error_action" Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Tested-by: John Snow <jsnow@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-03-26Merge remote-tracking branch ↵Peter Maydell1-1/+1
'remotes/palmer/tags/riscv-for-master-4.0-rc1-v2' into staging A second RISC-V Patch for 4.0.0-rc1 Sorry for sending two back-to-back pull requests. It looks like I misunderstood Kito and there were actually two patches necessary to fix the GCC test suite runs. # gpg: Signature made Tue 26 Mar 2019 10:20:20 GMT # gpg: using RSA key 00CE76D1834960DFCE886DF8EF4CA1502CCBAB41 # gpg: issuer "palmer@dabbelt.com" # gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [unknown] # gpg: aka "Palmer Dabbelt <palmer@sifive.com>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 00CE 76D1 8349 60DF CE88 6DF8 EF4C A150 2CCB AB41 * remotes/palmer/tags/riscv-for-master-4.0-rc1-v2: target/riscv: Fix wrong expanding for c.fswsp Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-26target/riscv: Fix wrong expanding for c.fswspKito Cheng1-1/+1
base register is no rs1 not rs2 for fsw. Signed-off-by: Kito Cheng <kito.cheng@gmail.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-03-26Merge remote-tracking branch 'remotes/armbru/tags/pull-pflash-2019-03-26' ↵Peter Maydell4-24/+59
into staging Pflash and firmware configuration patches for 2019-03-26 # gpg: Signature made Tue 26 Mar 2019 07:21:13 GMT # gpg: using RSA key 3870B400EB918653 # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * remotes/armbru/tags/pull-pflash-2019-03-26: pflash: Bury disabled code to limit device sizes pflash: Require backend size to match device, improve errors Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-26Merge remote-tracking branch 'remotes/armbru/tags/pull-misc-2019-03-26' into ↵Peter Maydell4-8/+4
staging Miscellaneous patches for 2019-03-26 # gpg: Signature made Tue 26 Mar 2019 07:10:23 GMT # gpg: using RSA key 3870B400EB918653 # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * remotes/armbru/tags/pull-misc-2019-03-26: qapi/qmp-dispatch: fix return value in do_qmp_dispatch json: Fix off-by-one assert check in next_state() xen-block: Replace qdict_put_obj() by qdict_put() where appropriate util/error: Remove an unnecessary NULL check Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-26Merge remote-tracking branch 'remotes/palmer/tags/riscv-for-master-4.0-rc1' ↵Peter Maydell2-2/+23
into staging A Single RISC-V Patch for 4.0-rc1 If this is too late I'm OK with it being in rc2, but it fixes a concrete regression and nobody has complained yet so I'd prefer it to be in rc1 if possible. The fix is to zero-extend the inputs to DIVUW and REMUW, which was exposed by the GCC test suite. # gpg: Signature made Tue 26 Mar 2019 05:54:20 GMT # gpg: using RSA key 00CE76D1834960DFCE886DF8EF4CA1502CCBAB41 # gpg: issuer "palmer@dabbelt.com" # gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [unknown] # gpg: aka "Palmer Dabbelt <palmer@sifive.com>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 00CE 76D1 8349 60DF CE88 6DF8 EF4C A150 2CCB AB41 * remotes/palmer/tags/riscv-for-master-4.0-rc1: target/riscv: Zero extend the inputs of divuw and remuw Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-26pflash: Bury disabled code to limit device sizesAlex Bennée2-13/+0
We disabled code to limit device sizes to 8, 16, 32 or 64MiB more than a decade ago in commit 95d1f3edd5e and c8b153d7949, v0.9.1. Bury. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [Extracted from a larger patch, extended to pflash_cfi02.c] Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190319163551.32499-3-armbru@redhat.com>
2019-03-26pflash: Require backend size to match device, improve errorsMarkus Armbruster4-11/+59
We reject undersized backends with a rather enigmatic "failed to read the initial flash content" error. For instance: $ qemu-system-ppc64 -S -display none -M sam460ex -drive if=pflash,format=raw,file=eins.img qemu-system-ppc64: Initialization of device cfi.pflash02 failed: failed to read the initial flash content We happily accept oversized images, ignoring their tail. Throwing away parts of firmware that way is pretty much certain to end in an even more enigmatic failure to boot. Require the backend's size to match the device's size exactly. Report mismatch like this: qemu-system-ppc64: Initialization of device cfi.pflash01 failed: device requires 1048576 bytes, block backend provides 512 bytes Improve the error for actual read failures to "can't read block backend". To avoid duplicating even more code between the two pflash device models, do all that in new helper blk_check_size_and_read_all(). The error reporting can still be confusing. For instance: qemu-system-ppc64 -S -display none -M taihu -drive if=pflash,format=raw,file=eins.img -drive if=pflash,unit=1,format=raw,file=zwei.img qemu-system-ppc64: Initialization of device cfi.pflash02 failed: device requires 2097152 bytes, block backend provides 512 bytes Leaves the user guessing which of the two -drive is wrong. Mention the issue in a TODO comment. Suggested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190319163551.32499-2-armbru@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-03-26qapi/qmp-dispatch: fix return value in do_qmp_dispatchVladimir Sementsov-Ogievskiy1-1/+1
There are no harm but just looks weird to return bool in pointer-returning function. Introduced in 69240fe62d1 with the whole failure-checking "if" chunk. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20190325154748.66381-1-vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2019-03-26json: Fix off-by-one assert check in next_state()Liam Merwick1-1/+1
The assert checking if the value of lexer->state in next_state(), which is used as an index to the 'json_lexer' array, incorrectly checks for an index value less than or equal to ARRAY_SIZE(json_lexer). Fix assert so that it just checks for an index less than the array size. Signed-off-by: Liam Merwick <liam.merwick@oracle.com> Message-Id: <1553169472-25325-1-git-send-email-liam.merwick@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2019-03-26xen-block: Replace qdict_put_obj() by qdict_put() where appropriateMarkus Armbruster1-2/+2
Patch created mechanically by rerunning: $ spatch --sp-file scripts/coccinelle/qobject.cocci \ --macro-file scripts/cocci-macro-file.h \ --dir hw/block --in-place Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190313174433.12966-1-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Acked-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2019-03-26util/error: Remove an unnecessary NULL checkPhilippe Mathieu-Daudé1-4/+0
This NULL check was required while introduced in 680d16dcb79f. Later refactor added a NULL check in error_setv(), so this check is now redundant. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190302223825.11192-2-philmd@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2019-03-25Merge remote-tracking branch ↵Peter Maydell9-135/+194
'remotes/juanquintela/tags/migration-pull-request' into staging Pull request - Rebase last pull request - Drop multifd - several other minor fixesLaLaLa # gpg: Signature made Mon 25 Mar 2019 17:46:29 GMT # gpg: using RSA key F487EF185872D723 # gpg: Good signature from "Juan Quintela <quintela@redhat.com>" [full] # gpg: aka "Juan Quintela <quintela@trasno.org>" [full] # Primary key fingerprint: 1899 FF8E DEBF 58CC EE03 4B82 F487 EF18 5872 D723 * remotes/juanquintela/tags/migration-pull-request: migration/postcopy: Update the bandwidth during postcopy Migration/colo.c: Make user obtain the last COLO mode info after failover Migration/colo.c: Add the necessary checks for colo_do_failover Migration/colo.c: Add new COLOExitReason to handle all failover state Migration/colo.c: Fix COLO failover status error migration/rdma: Check qemu_rdma_init_one_block migration: add support for a "tls-authz" migration parameter multifd: Drop x- multifd: Add some padding multifd: Change default packet size multifd: Be flexible about packet size multifd: Drop x-multifd-page-count parameter multifd: Create new next_packet_size field multifd: Rename "size" member to pages_alloc multifd: Only send pages when packet are not empty Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-25migration/postcopy: Update the bandwidth during postcopyDr. David Alan Gilbert1-1/+5
The recently added max-postcopy-bandwidth parameter is only read at the transition from precopy->postcopy where as the older max-bandwidth parameter updates the migration bandwidth when changed even if the migration is already running. Fix this discrepency so that: a) You can change the bandwidth during postcopy by setting max-postcopy-bandwidth b) Changing max-bandwidth during postcopy has no effect (it currently changes the postcopy bandwidth which isn't expected). Fixes: 7e555c6c bz: https://bugzilla.redhat.com/show_bug.cgi?id=1686321 Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-03-25Migration/colo.c: Make user obtain the last COLO mode info after failoverZhang Chen2-1/+22
Add the last_colo_mode to save the status after failover. This patch can solve the issue that user want to get last colo mode use query_colo_status after failover. Signed-off-by: Zhang Chen <chen.zhang@intel.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-03-25Migration/colo.c: Add the necessary checks for colo_do_failoverZhang Chen1-2/+8
Signed-off-by: Zhang Chen <chen.zhang@intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-03-25Migration/colo.c: Add new COLOExitReason to handle all failover stateZhang Chen2-17/+22
In this patch we add the processing state for COLOExitReason, because we have to identify COLO in the failover processing state or failover error state. In the way, we can handle all the failover state. We have improved the description of the COLOExitReason by the way. Signed-off-by: Zhang Chen <chen.zhang@intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-03-25Migration/colo.c: Fix COLO failover status errorZhang Chen1-3/+4
When finished COLO failover, the status is FAILOVER_STATUS_COMPLETED. The origin codes misunderstand the FAILOVER_STATUS_REQUIRE. Signed-off-by: Zhang Chen <chen.zhang@intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-03-25migration/rdma: Check qemu_rdma_init_one_blockDr. David Alan Gilbert1-1/+5
Actually it can't fail at the moment, but Coverity moans that it's the only place it's not checked, and it's an easy check. Reported-by: Coverity (CID 1399413) Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-03-25migration: add support for a "tls-authz" migration parameterDaniel P. Berrange4-2/+31
The QEMU instance that runs as the server for the migration data transport (ie the target QEMU) needs to be able to configure access control so it can prevent unauthorized clients initiating an incoming migration. This adds a new 'tls-authz' migration parameter that is used to provide the QOM ID of a QAuthZ subclass instance that provides the access control check. This is checked against the x509 certificate obtained during the TLS handshake. For example, when starting a QEMU for incoming migration, it is possible to give an example identity of the source QEMU that is intended to be connecting later: $QEMU \ -monitor stdio \ -incoming defer \ ...other args... (qemu) object_add tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\ endpoint=server,verify-peer=yes \ (qemu) object_add authz-simple,id=auth0,identity=CN=laptop.example.com,,\ O=Example Org,,L=London,,ST=London,,C=GB \ (qemu) migrate_incoming tcp:localhost:9000 Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-03-25multifd: Drop x-Juan Quintela3-35/+35
We make it supported from now on. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-03-25multifd: Add some paddingJuan Quintela1-0/+3
Add some padding. MultifdInit_t is padded to 64 bytes. MultiFDPacket_t is padded to 320bytes (64 * 5). Signed-off-by: Juan Quintela <quintela@redhat.com>
2019-03-25multifd: Change default packet sizeJuan Quintela1-1/+1
We moved from 64KB to 512KB, as it makes less locking contention without any downside in testing. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
generated by cgit v1.1 at 2025-03-11 07:48:13 +0000