aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-01-24accel: Introduce the current_accel() wrapperPhilippe Mathieu-Daudé
The accel/ code only accesses the MachineState::accel field. As we simply want to access the accelerator, not the machine, add a current_accel() wrapper. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20200121110349.25842-9-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24qom/object: Display more helpful message when a parent is missingPhilippe Mathieu-Daudé
QEMU object model is scarse in documentation. Some calls are recursive, and it might be hard to figure out even trivial issues. We can avoid developers to waste time in a debugging session by displaying a simple error message. This commit is also similar to e02bdf1cecd2 ("Display more helpful message when an object type is missing"). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20200121110349.25842-7-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24target/arm/kvm: Use CPUState::kvm_state in kvm_arm_pmu_supported()Philippe Mathieu-Daudé
KVMState is already accessible via CPUState::kvm_state, use it. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200121110349.25842-5-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24hw/ppc/spapr_rtas: Remove local variablePhilippe Mathieu-Daudé
We only access this variable in the RTAS_SYSPARM_SPLPAR_CHARACTERISTICS case. Use it in place and remove the local declaration. Suggested-by: Greg Kurz <groug@kaod.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200121110349.25842-4-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24hw/ppc/spapr_rtas: Access MachineState via SpaprMachineState argumentPhilippe Mathieu-Daudé
We received a SpaprMachineState argument. Since SpaprMachineState inherits of MachineState, use it instead of calling qdev_get_machine. Reviewed-by: Greg Kurz <groug@kaod.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200121110349.25842-3-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24hw/ppc/spapr_rtas: Use local MachineState variablePhilippe Mathieu-Daudé
Since we have the MachineState already available locally, use it instead of the global current_machine. Reviewed-by: Greg Kurz <groug@kaod.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200121110349.25842-2-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24virtio-scsi: convert to new virtio_delete_queuePan Nengyuan
Use virtio_delete_queue to make it more clear. Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200117075547.60864-3-pannengyuan@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24virtio-scsi: delete vqs in unrealize to avoid memleaksPan Nengyuan
This patch fix memleaks when attaching/detaching virtio-scsi device, the memory leak stack is as follow: Direct leak of 21504 byte(s) in 3 object(s) allocated from: #0 0x7f491f2f2970 (/lib64/libasan.so.5+0xef970) ??:? #1 0x7f491e94649d (/lib64/libglib-2.0.so.0+0x5249d) ??:? #2 0x564d0f3919fa (./x86_64-softmmu/qemu-system-x86_64+0x2c3e9fa) /mnt/sdb/qemu/hw/virtio/virtio.c:2333 #3 0x564d0f2eca55 (./x86_64-softmmu/qemu-system-x86_64+0x2b99a55) /mnt/sdb/qemu/hw/scsi/virtio-scsi.c:912 #4 0x564d0f2ece7b (./x86_64-softmmu/qemu-system-x86_64+0x2b99e7b) /mnt/sdb/qemu/hw/scsi/virtio-scsi.c:924 #5 0x564d0f39ee47 (./x86_64-softmmu/qemu-system-x86_64+0x2c4be47) /mnt/sdb/qemu/hw/virtio/virtio.c:3531 #6 0x564d0f980224 (./x86_64-softmmu/qemu-system-x86_64+0x322d224) /mnt/sdb/qemu/hw/core/qdev.c:865 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200117075547.60864-2-pannengyuan@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24target/i386: kvm: initialize microcode revision from KVMPaolo Bonzini
KVM can return the host microcode revision as a feature MSR. Use it as the default value for -cpu host. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <1579544504-3616-4-git-send-email-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24target/i386: add a ucode-rev propertyPaolo Bonzini
Add the property and plumb it in TCG and HVF (the latter of which tried to support returning a constant value but used the wrong MSR). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <1579544504-3616-3-git-send-email-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24target/i386: kvm: initialize feature MSRs very earlyPaolo Bonzini
Some read-only MSRs affect the behavior of ioctls such as KVM_SET_NESTED_STATE. We can initialize them once and for all right after the CPU is realized, since they will never be modified by the guest. Reported-by: Qingua Cheng <qcheng@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <1579544504-3616-2-git-send-email-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24hw/core/Makefile: Group generic objects versus system-mode objectsPhilippe Mathieu-Daudé
To ease review/modifications of this Makefile, group generic objects first, then system-mode specific ones, and finally peripherals (which are only used in system-mode). No logical changes introduced here. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200118140619.26333-7-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24hw/core: Restrict reset handlers API to system-modePhilippe Mathieu-Daudé
The user-mode code does not use this API, restrict it to the system-mode. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20200118140619.26333-6-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24Makefile: Remove unhelpful commentPhilippe Mathieu-Daudé
It is pointless to keep qapi/ object separate from the other common-objects. Drop the comment. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200118140619.26333-5-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24Makefile: Restrict system emulation and tools objectsPhilippe Mathieu-Daudé
Restrict all the system emulation and tools objects with a Makefile IF (CONFIG_SOFTMMU OR CONFIG_TOOLS) check. Using the same description over and over is not very helpful. Use it once, just before the if() block. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200118140619.26333-4-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24Makefile: Clarify all the codebase requires qom/ objectsPhilippe Mathieu-Daudé
QEMU user-mode also requires the qom/ objects, it is not only used by "system emulation and qemu-img". As we will use a big if() block, move it upper in the "Common libraries for tools and emulators" section. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200118140619.26333-3-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24configure: Do not build libfdt if not requiredPhilippe Mathieu-Daudé
We only require libfdt for system emulation, in a small set of architecture: 4077 # fdt support is mandatory for at least some target architectures, 4078 # so insist on it if we're building those system emulators. 4079 fdt_required=no 4080 for target in $target_list; do 4081 case $target in 4082 aarch64*-softmmu|arm*-softmmu|ppc*-softmmu|microblaze*-softmmu|mips64el-softmmu|riscv*-softmmu) 4083 fdt_required=yes Do not build libfdt if we did not manually specified --enable-fdt, or have one of the platforms that require it in our target list. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200118140619.26333-2-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24hw/pci-host/designware: Remove unuseful FALLTHROUGH commentPhilippe Mathieu-Daudé
We don't need to explicit this obvious switch fall through. Stay consistent with the rest of the codebase. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20191218192526.13845-7-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24hw/net/imx_fec: Remove unuseful FALLTHROUGH commentsPhilippe Mathieu-Daudé
We don't need to explicit these obvious switch fall through comments. Stay consistent with the rest of the codebase. Suggested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20191218192526.13845-6-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24hw/net/imx_fec: Rewrite fall through commentsPhilippe Mathieu-Daudé
GCC9 is confused by this comment when building with CFLAG -Wimplicit-fallthrough=2: hw/net/imx_fec.c: In function ‘imx_eth_write’: hw/net/imx_fec.c:906:12: error: this statement may fall through [-Werror=implicit-fallthrough=] 906 | if (unlikely(single_tx_ring)) { | ^ hw/net/imx_fec.c:912:5: note: here 912 | case ENET_TDAR: /* FALLTHROUGH */ | ^~~~ cc1: all warnings being treated as errors Rewrite the comments in the correct place, using 'fall through' which is recognized by GCC and static analyzers. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20191218192526.13845-5-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24hw/timer/aspeed_timer: Add a fall through commentPhilippe Mathieu-Daudé
Reported by GCC9 when building with CFLAG -Wimplicit-fallthrough=2: hw/timer/aspeed_timer.c: In function ‘aspeed_timer_set_value’: hw/timer/aspeed_timer.c:283:24: error: this statement may fall through [-Werror=implicit-fallthrough=] 283 | if (old_reload || !t->reload) { | ~~~~~~~~~~~^~~~~~~~~~~~~ hw/timer/aspeed_timer.c:287:5: note: here 287 | case TIMER_REG_STATUS: | ^~~~ cc1: all warnings being treated as errors Add the missing fall through comment. Fixes: 1403f364472 Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191218192526.13845-4-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24hw/display/tcx: Add missing fall through commentsPhilippe Mathieu-Daudé
When building with GCC9 using CFLAG -Wimplicit-fallthrough=2 we get: hw/display/tcx.c: In function ‘tcx_dac_writel’: hw/display/tcx.c:453:26: error: this statement may fall through [-Werror=implicit-fallthrough=] 453 | s->dac_index = (s->dac_index + 1) & 0xff; /* Index autoincrement */ | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~ hw/display/tcx.c:454:9: note: here 454 | default: | ^~~~~~~ hw/display/tcx.c: In function ‘tcx_dac_readl’: hw/display/tcx.c:412:22: error: this statement may fall through [-Werror=implicit-fallthrough=] 412 | s->dac_index = (s->dac_index + 1) & 0xff; /* Index autoincrement */ | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~ hw/display/tcx.c:413:5: note: here 413 | default: | ^~~~~~~ cc1: all warnings being treated as errors Give a hint to GCC by adding the missing fall through comments. Fixes: 55d7bfe22 Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <20191218192526.13845-3-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24audio/audio: Add missing fall through commentPhilippe Mathieu-Daudé
When building with GCC9 using CFLAG -Wimplicit-fallthrough=2 we get: audio/audio.c: In function ‘audio_pcm_init_info’: audio/audio.c:306:14: error: this statement may fall through [-Werror=implicit-fallthrough=] 306 | sign = 1; | ~~~~~^~~ audio/audio.c:307:5: note: here 307 | case AUDIO_FORMAT_U8: | ^~~~ cc1: all warnings being treated as errors Similarly to e46349414, add the missing fall through comment to hint GCC. Fixes: 2b9cce8c8c Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20191218192526.13845-2-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24qom/object: Display more helpful message when an interface is missingPhilippe Mathieu-Daudé
When adding new devices implementing QOM interfaces, we might forgot to add the Kconfig dependency that pulls the required objects in when building. Since QOM dependencies are resolved at runtime, we don't get any link-time failures, and QEMU aborts while starting: $ qemu ... Segmentation fault (core dumped) (gdb) bt #0 0x00007ff6e96b1e35 in raise () from /lib64/libc.so.6 #1 0x00007ff6e969c895 in abort () from /lib64/libc.so.6 #2 0x00005572bc5051cf in type_initialize (ti=0x5572be6f1200) at qom/object.c:323 #3 0x00005572bc505074 in type_initialize (ti=0x5572be6f1800) at qom/object.c:301 #4 0x00005572bc505074 in type_initialize (ti=0x5572be6e48e0) at qom/object.c:301 #5 0x00005572bc506939 in object_class_by_name (typename=0x5572bc56109a) at qom/object.c:959 #6 0x00005572bc503dd5 in cpu_class_by_name (typename=0x5572bc56109a, cpu_model=0x5572be6d9930) at hw/core/cpu.c:286 Since the caller has access to the qdev parent/interface names, we can simply display them to avoid starting a debugger: $ qemu ... qemu: missing interface 'fancy-if' for object 'fancy-dev' Aborted (core dumped) This commit is similar to e02bdf1cecd2 ("Display more helpful message when an object type is missing"). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200118162348.17823-1-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24pvpanic: implement crashloaded event handlingzhenwei pi
Handle bit 1 write, then post event to monitor. Suggested by Paolo, declear a new event, using GUEST_PANICKED could cause upper layers to react by shutting down or rebooting the guest. In advance for extention, add GuestPanicInformation in event message. Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20200114023102.612548-3-pizhenwei@bytedance.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24pvpanic: introduce crashloaded for pvpaniczhenwei pi
Add bit 1 for pvpanic. This bit means that guest hits a panic, but guest wants to handle error by itself. Typical case: Linux guest runs kdump in panic. It will help us to separate the abnormal reboot from normal operation. Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20200114023102.612548-2-pizhenwei@bytedance.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24cpu: Use cpu_class_set_parent_reset()Greg Kurz
Convert all targets to use cpu_class_set_parent_reset() with the following coccinelle script: @@ type CPUParentClass; CPUParentClass *pcc; CPUClass *cc; identifier parent_fn; identifier child_fn; @@ +cpu_class_set_parent_reset(cc, child_fn, &pcc->parent_fn); -pcc->parent_fn = cc->reset; ... -cc->reset = child_fn; Signed-off-by: Greg Kurz <groug@kaod.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: David Hildenbrand <david@redhat.com> Message-Id: <157650847817.354886.7047137349018460524.stgit@bahia.lan> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24cpu: Introduce cpu_class_set_parent_reset()Greg Kurz
Similarly to what we already do with qdev, use a helper to overload the reset QOM methods of the parent in children classes, for clarity. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: David Hildenbrand <david@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <157650847239.354886.2782881118916307978.stgit@bahia.lan> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-21Merge remote-tracking branch 'remotes/philmd-gitlab/tags/edk2-next-20200121' ↵Peter Maydell
into staging EDK2 firmware patches Another set of build-sys patches, to help building the firmware binaries we use for testing. We almost have reproducible builds. # gpg: Signature made Tue 21 Jan 2020 15:14:09 GMT # gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full] # Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE * remotes/philmd-gitlab/tags/edk2-next-20200121: gitlab-ci.yml: Add jobs to build EDK2 firmware binaries roms/edk2-funcs: Force softfloat ARM toolchain prefix on Debian Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-21gitlab-ci.yml: Add jobs to build EDK2 firmware binariesPhilippe Mathieu-Daudé
Add two GitLab job to build the EDK2 firmware binaries. The first job build a Docker image with the packages requisite to build EDK2, and store this image in the GitLab registry. The second job pull the image from the registry and build the EDK2 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/edk2/ submodule is updated, when a git-ref starts with 'edk2' or when the last commit contains 'EDK2'. The files generated are archived in the artifacts.zip file. With edk2-stable201905, it took 2 minutes 52 seconds to build the docker image, and 36 minutes 28 seconds to generate the artifacts.zip with the firmware binaries (filesize: 10MiB). See: https://gitlab.com/philmd/qemu/pipelines/107553178 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-01-21roms/edk2-funcs: Force softfloat ARM toolchain prefix on DebianPhilippe Mathieu-Daudé
The Debian (based) distributions currently provides 2 ARM toolchains, documented as [1]: * The ARM EABI (armel) port targets a range of older 32-bit ARM devices, particularly those used in NAS hardware and a variety of *plug computers. * The newer ARM hard-float (armhf) port supports newer, more powerful 32-bit devices using version 7 of the ARM architecture specification. For various reasons documented in [2], the EDK2 project suggests to use the softfloat toolchain (named 'armel' by Debian). Force the softfloat cross toolchain prefix on Debian distributions. [1] https://www.debian.org/ports/arm/#status [2] https://github.com/tianocore/edk2/commit/41203b9a Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-01-21Merge remote-tracking branch 'remotes/vivier/tags/m68k-for-5.0-pull-request' ↵Peter Maydell
into staging Fix m68k single-stepping with remote gdb # gpg: Signature made Tue 21 Jan 2020 12:21:12 GMT # gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C # gpg: issuer "laurent@vivier.eu" # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full] # gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full] # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full] # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C * remotes/vivier/tags/m68k-for-5.0-pull-request: m68k: Fix regression causing Single-Step via GDB/RSP to not single step Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-21m68k: Fix regression causing Single-Step via GDB/RSP to not single stepLaurent Vivier
A regression that was introduced, with the refactor to TranslatorOps, drops two lines that update the PC when single-stepping is being performed. Fixes: 11ab74b01e0a ("target/m68k: Convert to TranslatorOps") Reported-by: Lucien Murray-Pitts <lucienmp_antispam@yahoo.com> Suggested-by: Lucien Murray-Pitts <lucienmp_antispam@yahoo.com> Suggested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20200116165454.2076265-1-laurent@vivier.eu>
2020-01-21Makefile: add missing mkdir MANUAL_BUILDDIRStefan Hajnoczi
The MANUAL_BUILDDIR directory is automatically created by sphinx-build for the other targets. The index.html target does not use sphinx-build so we must manually create the directory to avoid the following error: GEN docs/built/index.html /bin/sh: docs/built/index.html: No such file or directory Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20200120163400.603449-1-stefanha@redhat.com Reviewed-by: Miroslav Rezanina <mrezanin@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-20Merge remote-tracking branch 'remotes/gkurz/tags/9p-next-2020-01-20' into ↵Peter Maydell
staging Assorted fixes and cleanups. v2: - fix 32-bit build # gpg: Signature made Mon 20 Jan 2020 14:14:11 GMT # gpg: using RSA key B4828BAF943140CEF2A3491071D4D5E5822F73D6 # gpg: Good signature from "Greg Kurz <groug@kaod.org>" [full] # gpg: aka "Gregory Kurz <gregory.kurz@free.fr>" [full] # gpg: aka "[jpeg image of size 3330]" [full] # Primary key fingerprint: B482 8BAF 9431 40CE F2A3 4910 71D4 D5E5 822F 73D6 * remotes/gkurz/tags/9p-next-2020-01-20: 9pfs/9p.c: remove unneeded labels virtfs-proxy-helper.c: remove 'err_out' label in setugid() 9p: init_in_iov_from_pdu can truncate the size 9p: local: always return -1 on error in local_unlinkat_common 9pfs: local: Fix possible memory leak in local_link() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-209pfs/9p.c: remove unneeded labelsDaniel Henrique Barboza
'out' label in v9fs_xattr_write() and 'out_nofid' label in v9fs_complete_rename() can be replaced by appropriate return calls. CC: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Acked-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
2020-01-20virtfs-proxy-helper.c: remove 'err_out' label in setugid()Daniel Henrique Barboza
'err_out' can be removed and be replaced by 'return -errno' in its only instance in the function. CC: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Acked-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
2020-01-209p: init_in_iov_from_pdu can truncate the sizeGreg Kurz
init_in_iov_from_pdu might not be able to allocate the full buffer size requested, which comes from the client and could be larger than the transport has available at the time of the request. Specifically, this can happen with read operations, with the client requesting a read up to the max allowed, which might be more than the transport has available at the time. Today the implementation of init_in_iov_from_pdu throws an error, both Xen and Virtio. Instead, change the V9fsTransport interface so that the size becomes a pointer and can be limited by the implementation of init_in_iov_from_pdu. Change both the Xen and Virtio implementations to set the size to the size of the buffer they managed to allocate, instead of throwing an error. However, if the allocated buffer size is less than P9_IOHDRSZ (the size of the header) still throw an error as the case is unhandable. Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> CC: groug@kaod.org CC: anthony.perard@citrix.com CC: roman@zededa.com CC: qemu_oss@crudebyte.com [groug: fix 32-bit build] Signed-off-by: Greg Kurz <groug@kaod.org>
2020-01-209p: local: always return -1 on error in local_unlinkat_commonDaniel Henrique Barboza
local_unlinkat_common() is supposed to always return -1 on error. This is being done by jumps to the 'err_out' label, which is a 'return ret' call, and 'ret' is initialized with -1. Unfortunately there is a condition in which the function will return 0 on error: in a case where flags == AT_REMOVEDIR, 'ret' will be 0 when reaching map_dirfd = openat_dir(...) And, if map_dirfd == -1 and errno != ENOENT, the existing 'err_out' jump will execute 'return ret', when ret is still set to zero at that point. This patch fixes it by changing all 'err_out' labels by 'return -1' calls, ensuring that the function will always return -1 on error conditions. 'ret' can be left unintialized since it's now being used just to store the result of 'unlinkat' calls. CC: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> [groug: changed prefix in title to be "9p: local:"] Signed-off-by: Greg Kurz <groug@kaod.org>
2020-01-209pfs: local: Fix possible memory leak in local_link()Jiajun Chen
There is a possible memory leak while local_link return -1 without free odirpath and oname. Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Jaijun Chen <chenjiajun8@huawei.com> Signed-off-by: Xiang Zheng <zhengxiang9@huawei.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org>
2020-01-20qapi: Fix code generation with Python 3.5Markus Armbruster
Recent commit 3e7fb5811b "qapi: Fix code generation for empty modules" modules" switched QAPISchema.visit() from for entity in self._entity_list: effectively to for mod in self._module_dict.values(): for entity in mod._entity_list: Visits in the same order as long as .values() is in insertion order. That's the case only for Python 3.6 and later. Before, it's in some arbitrary order, which results in broken generated code. Fix by making self._module_dict an OrderedDict rather than a dict. Fixes: 3e7fb5811baab213dcc7149c3aa69442d683c26c Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Thomas Huth <thuth@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Tested-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20200116202558.31473-1-armbru@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-20Merge remote-tracking branch ↵Peter Maydell
'remotes/juanquintela/tags/migration-pull-pull-request' into staging Migration pull request # gpg: Signature made Mon 20 Jan 2020 10:29:53 GMT # gpg: using RSA key 1899FF8EDEBF58CCEE034B82F487EF185872D723 # 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-pull-request: (29 commits) multifd: Be consistent about using uint64_t migration: Support QLIST migration apic: Use 32bit APIC ID for migration instance ID migration: Change SaveStateEntry.instance_id into uint32_t migration: Define VMSTATE_INSTANCE_ID_ANY Bug #1829242 correction. migration/multifd: fix destroyed mutex access in terminating multifd threads migration/multifd: fix nullptr access in terminating multifd threads migration/multifd: not use multifd during postcopy migration/multifd: clean pages after filling packet migration/postcopy: enable compress during postcopy migration/postcopy: enable random order target page arrival migration/postcopy: set all_zero to true on the first target page migration/postcopy: count target page number to decide the place_needed migration/postcopy: wait for decompress thread in precopy migration/postcopy: reduce memset when it is zero page and matches_target_page_size migration/ram: Yield periodically to the main loop migration: savevm_state_handler_insert: constant-time element insertion migration: add savevm_state_handler_remove() misc: use QEMU_IS_ALIGNED ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-20multifd: Be consistent about using uint64_tJuan Quintela
We transmit ram_addr_t always as uint64_t. Be consistent in its use (on 64bit system, it is always uint64_t problem is 32bits). Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-01-20migration: Support QLIST migrationEric Auger
Support QLIST migration using the same principle as QTAILQ: 94869d5c52 ("migration: migrate QTAILQ"). The VMSTATE_QLIST_V macro has the same proto as VMSTATE_QTAILQ_V. The change mainly resides in QLIST RAW macros: QLIST_RAW_INSERT_HEAD and QLIST_RAW_REVERSE. Tests also are provided. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20apic: Use 32bit APIC ID for migration instance IDPeter Xu
Migration is silently broken now with x2apic config like this: -smp 200,maxcpus=288,sockets=2,cores=72,threads=2 \ -device intel-iommu,intremap=on,eim=on After migration, the guest kernel could hang at anything, due to x2apic bit not migrated correctly in IA32_APIC_BASE on some vcpus, so any operations related to x2apic could be broken then (e.g., RDMSR on x2apic MSRs could fail because KVM would think that the vcpu hasn't enabled x2apic at all). The issue is that the x2apic bit was never applied correctly for vcpus whose ID > 255 when migrate completes, and that's because when we migrate APIC we use the APICCommonState.id as instance ID of the migration stream, while that's too short for x2apic. Let's use the newly introduced initial_apic_id for that. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration: Change SaveStateEntry.instance_id into uint32_tPeter Xu
It was always used as 32bit, so define it as used to be clear. Instead of using -1 as the auto-gen magic value, we switch to UINT32_MAX. We also make sure that we don't auto-gen this value to avoid overflowed instance IDs without being noticed. Suggested-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration: Define VMSTATE_INSTANCE_ID_ANYPeter Xu
Define the new macro VMSTATE_INSTANCE_ID_ANY for callers who wants to auto-generate the vmstate instance ID. Previously it was hard coded as -1 instead of this macro. It helps to change this default value in the follow up patches. No functional change. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20Bug #1829242 correction.Alexey Romko
Added type conversions to ram_addr_t before all left shifts of page indexes to TARGET_PAGE_BITS, to correct overflows when the page address was 4Gb and more. Signed-off-by: Alexey Romko <nevilad@yahoo.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration/multifd: fix destroyed mutex access in terminating multifd threadsJiahui Cen
One multifd will lock all the other multifds' IOChannel mutex to inform them to quit by setting p->quit or shutting down p->c. In this senario, if some multifds had already been terminated and multifd_load_cleanup/multifd_save_cleanup had destroyed their mutex, it could cause destroyed mutex access when trying lock their mutex. Here is the coredump stack: #0 0x00007f81a2794437 in raise () from /usr/lib64/libc.so.6 #1 0x00007f81a2795b28 in abort () from /usr/lib64/libc.so.6 #2 0x00007f81a278d1b6 in __assert_fail_base () from /usr/lib64/libc.so.6 #3 0x00007f81a278d262 in __assert_fail () from /usr/lib64/libc.so.6 #4 0x000055eb1bfadbd3 in qemu_mutex_lock_impl (mutex=0x55eb1e2d1988, file=<optimized out>, line=<optimized out>) at util/qemu-thread-posix.c:64 #5 0x000055eb1bb4564a in multifd_send_terminate_threads (err=<optimized out>) at migration/ram.c:1015 #6 0x000055eb1bb4bb7f in multifd_send_thread (opaque=0x55eb1e2d19f8) at migration/ram.c:1171 #7 0x000055eb1bfad628 in qemu_thread_start (args=0x55eb1e170450) at util/qemu-thread-posix.c:502 #8 0x00007f81a2b36df5 in start_thread () from /usr/lib64/libpthread.so.0 #9 0x00007f81a286048d in clone () from /usr/lib64/libc.so.6 To fix it up, let's destroy the mutex after all the other multifd threads had been terminated. Signed-off-by: Jiahui Cen <cenjiahui@huawei.com> Signed-off-by: Ying Fang <fangying1@huawei.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration/multifd: fix nullptr access in terminating multifd threadsJiahui Cen
One multifd channel will shutdown all the other multifd's IOChannel when it fails to receive an IOChannel. In this senario, if some multifds had not received its IOChannel yet, it would try to shutdown its IOChannel which could cause nullptr access at qio_channel_shutdown. Here is the coredump stack: #0 object_get_class (obj=obj@entry=0x0) at qom/object.c:908 #1 0x00005563fdbb8f4a in qio_channel_shutdown (ioc=0x0, how=QIO_CHANNEL_SHUTDOWN_BOTH, errp=0x0) at io/channel.c:355 #2 0x00005563fd7b4c5f in multifd_recv_terminate_threads (err=<optimized out>) at migration/ram.c:1280 #3 0x00005563fd7bc019 in multifd_recv_new_channel (ioc=ioc@entry=0x556400255610, errp=errp@entry=0x7ffec07dce00) at migration/ram.c:1478 #4 0x00005563fda82177 in migration_ioc_process_incoming (ioc=ioc@entry=0x556400255610, errp=errp@entry=0x7ffec07dce30) at migration/migration.c:605 #5 0x00005563fda8567d in migration_channel_process_incoming (ioc=0x556400255610) at migration/channel.c:44 #6 0x00005563fda83ee0 in socket_accept_incoming_migration (listener=0x5563fff6b920, cioc=0x556400255610, opaque=<optimized out>) at migration/socket.c:166 #7 0x00005563fdbc25cd in qio_net_listener_channel_func (ioc=<optimized out>, condition=<optimized out>, opaque=<optimized out>) at io/net-listener.c:54 #8 0x00007f895b6fe9a9 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #9 0x00005563fdc18136 in glib_pollfds_poll () at util/main-loop.c:218 #10 0x00005563fdc181b5 in os_host_main_loop_wait (timeout=1000000000) at util/main-loop.c:241 #11 0x00005563fdc183a2 in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:517 #12 0x00005563fd8edb37 in main_loop () at vl.c:1791 #13 0x00005563fd74fd45 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4473 To fix it up, let's check p->c before calling qio_channel_shutdown. Signed-off-by: Jiahui Cen <cenjiahui@huawei.com> Signed-off-by: Ying Fang <fangying1@huawei.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-02-02 15:15:08 +0000