aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2020-01-24Merge remote-tracking branch 'remotes/palmer/tags/riscv-for-master-5.0-sf1' ↵Peter Maydell1-0/+1
into staging RISC-V Patches for the 5.0 Soft Freeze, Part 1 This patch set contains a handful of collected fixes that I'd like to target for the 5.0 soft freeze (I know that's a long way away, I just don't know what else to call these): * A fix for a memory leak initializing the sifive_u board. * Fixes to privilege mode emulation related to interrupts and fstatus. Notably absent is the H extension implementation. That's pretty much reviewed, but not quite ready to go yet and I didn't want to hold back these important fixes. This boots 32-bit and 64-bit Linux (buildroot this time, just for fun) and passes "make check". # gpg: Signature made Tue 21 Jan 2020 22:55:28 GMT # gpg: using RSA key 2B3C3747446843B24A943A7A2E1319F35FBB1889 # gpg: issuer "palmer@dabbelt.com" # gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [unknown] # gpg: aka "Palmer Dabbelt <palmer@sifive.com>" [unknown] # gpg: aka "Palmer Dabbelt <palmerdabbelt@google.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 # Subkey fingerprint: 2B3C 3747 4468 43B2 4A94 3A7A 2E13 19F3 5FBB 1889 * remotes/palmer/tags/riscv-for-master-5.0-sf1: target/riscv: update mstatus.SD when FS is set dirty target/riscv: fsd/fsw doesn't dirty FP state target/riscv: Fix tb->flags FS status riscv: Set xPIE to 1 after xRET riscv/sifive_u: fix a memory leak in soc_realize() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-24Merge remote-tracking branch ↵Peter Maydell1-1/+1
'remotes/dgilbert-gitlab/tags/pull-virtiofs-20200123b' into staging virtiofsd first pull v2 Import our virtiofsd. This pulls in the daemon to drive a file system connected to the existing qemu virtiofsd device. It's derived from upstream libfuse with lots of changes (and a lot trimmed out). The daemon lives in the newly created qemu/tools/virtiofsd Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> v2 drop the docs while we discuss where they should live and we need to redo the manpage in anything but texi # gpg: Signature made Thu 23 Jan 2020 16:45:18 GMT # gpg: using RSA key 45F5C71B4A0CB7FB977A9FA90516331EBC5BFDE7 # gpg: Good signature from "Dr. David Alan Gilbert (RH2) <dgilbert@redhat.com>" [full] # Primary key fingerprint: 45F5 C71B 4A0C B7FB 977A 9FA9 0516 331E BC5B FDE7 * remotes/dgilbert-gitlab/tags/pull-virtiofs-20200123b: (108 commits) virtiofsd: add some options to the help message virtiofsd: stop all queue threads on exit in virtio_loop() virtiofsd/passthrough_ll: Pass errno to fuse_reply_err() virtiofsd: Convert lo_destroy to take the lo->mutex lock itself virtiofsd: add --thread-pool-size=NUM option virtiofsd: fix lo_destroy() resource leaks virtiofsd: prevent FUSE_INIT/FUSE_DESTROY races virtiofsd: process requests in a thread pool virtiofsd: use fuse_buf_writev to replace fuse_buf_write for better performance virtiofsd: add definition of fuse_buf_writev() virtiofsd: passthrough_ll: Use cache_readdir for directory open virtiofsd: Fix data corruption with O_APPEND write in writeback mode virtiofsd: Reset O_DIRECT flag during file open virtiofsd: convert more fprintf and perror to use fuse log infra virtiofsd: do not always set FUSE_FLOCK_LOCKS virtiofsd: introduce inode refcount to prevent use-after-free virtiofsd: passthrough_ll: fix refcounting on remove/rename libvhost-user: Fix some memtable remap cases virtiofsd: rename inode->refcount to inode->nlookup virtiofsd: prevent races with lo_dirp_put() ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-23vhost-user: Print unexpected slave message typesDr. David Alan Gilbert1-1/+1
When we receive an unexpected message type on the slave fd, print the type. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-01-23hw/arm/exynos4210: Connect serial port DMA busy signals with pl330Guenter Roeck1-13/+29
The Exynos4210 serial driver uses an interrupt line to signal if receive data is available. Connect that interrupt with the DMA controller's 'peripheral busy' gpio pin to stop the DMA if there is no more receive data available. Without this patch, receive DMA runs wild and fills the entire receive DMA buffer with invalid data. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20200123052540.6132-9-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-23hw/char/exynos4210_uart: Add receive DMA supportGuenter Roeck2-0/+26
To support receive DMA, we need to inform the DMA controller if receive data is available. Otherwise the DMA controller keeps requesting data, causing receive errors. Implement this using an interrupt line. The instantiating code then needs to connect the interrupt with the matching DMA controller GPIO pin. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20200123052540.6132-8-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-23hw/char/exynos4210_uart: Implement Rx FIFO level triggers and timeoutsGuenter Roeck2-26/+94
The driver already implements a receive FIFO, but it does not handle receive FIFO trigger levels and timeout. Implement the missing functionality. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20200123052540.6132-7-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-23hw/char/exynos4210_uart: Implement post_load functionGuenter Roeck1-0/+10
After restoring a VM, serial parameters need to be updated to reflect restored register values. Implement a post_load function to handle this situation. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20200123052540.6132-6-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-23hw/char/exynos4210_uart: Convert to support tracingGuenter Roeck2-66/+47
Replace debug code with tracing to aid debugging. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20200123052540.6132-5-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-23hw/arm/exynos4210: Fix DMA initializationGuenter Roeck1-8/+43
First parameter to exynos4210_get_irq() is not the SPI port number, but the interrupt group number. Interrupt groups are 20 for mdma and 21 for pdma. Interrupts are not inverted. Controllers support 32 events (pdma) or 31 events (mdma). Events must all be routed to a single interrupt line. Set other parameters as documented in Exynos4210 datasheet, section 8 (DMA controller). Fixes: 59520dc65e ("hw/arm/exynos4210: Add DMA support for the Exynos4210") Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20200123052540.6132-4-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-23dma/pl330: Convert to support tracingGuenter Roeck2-40/+72
Replace debug logging code with tracing. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20200123052540.6132-2-linux@roeck-us.net [PMM: tweak dmald/dmast trace events to fix OSX-only format string complaint] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-23hw/misc/stm32f4xx_syscfg: Fix copy/paste errorPhilippe Mathieu-Daudé1-1/+1
Missed in 870c034da0b, hopefully reported by Coverity. Fixes: Coverity CID 1412793 (Incorrect expression) Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20200121213853.9601-1-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-23hw/arm: Use helper function to trigger hotplug handler plugKeqian Zhu1-3/+3
We can use existing helper function to trigger hotplug handler plug, which makes code clearer. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com> Message-id: 20200120012755.44581-3-zhukeqian1@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-23hw/acpi: Remove extra indent in ACPI GED hotplug cbKeqian Zhu1-1/+1
There is extra indent in ACPI GED hotplug cb that should be deleted. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com> Message-id: 20200120012755.44581-2-zhukeqian1@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-23vhost: coding style fixMichael S. Tsirkin1-3/+3
Drop a trailing whitespace. Make line shorter. Fixes: 76525114736e8 ("vhost: Only align sections for vhost-user") Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-01-22i386:acpi: Remove _HID from the SMBus ACPI entryCorey Minyard1-1/+0
Per the ACPI spec (version 6.1, section 6.1.5 _HID) it is not required on enumerated buses (like PCI in this case), _ADR is required (and is already there). And the _HID value is wrong. Linux appears to ignore the _HID entry, but Windows 10 detects it as 'Unknown Device' and there is no driver available. See https://bugs.launchpad.net/qemu/+bug/1856724 Signed-off-by: Corey Minyard <cminyard@mvista.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200120170725.24935-6-minyard@acm.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-01-22vhost: Only align sections for vhost-userDr. David Alan Gilbert1-16/+18
I added hugepage alignment code in c1ece84e7c9 to deal with vhost-user + postcopy which needs aligned pages when using userfault. However, on x86 the lower 2MB of address space tends to be shotgun'd with small fragments around the 512-640k range - e.g. video RAM, and with HyperV synic pages tend to sit around there - again splitting it up. The alignment code complains with a 'Section rounded to ...' error and gives up. Since vhost-user already filters out devices without an fd (see vhost-user.c vhost_user_mem_section_filter) it shouldn't be affected by those overlaps. Turn the alignment off on vhost-kernel so that it doesn't try and align, and thus won't hit the rounding issues. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20200116202414.157959-3-dgilbert@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-22vhost: Add names to section rounded warningDr. David Alan Gilbert1-3/+4
Add the memory region names to section rounding/alignment warnings. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20200116202414.157959-2-dgilbert@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-01-22vhost-vsock: delete vqs in vhost_vsock_unrealize to avoid memleaksPan Nengyuan1-2/+10
Receive/transmit/event vqs forgot to cleanup in vhost_vsock_unrealize. This patch save receive/transmit vq pointer in realize() and cleanup vqs through those vq pointers in unrealize(). The leak stack is as follow: Direct leak of 21504 byte(s) in 3 object(s) allocated from: #0 0x7f86a1356970 (/lib64/libasan.so.5+0xef970) ??:? #1 0x7f86a09aa49d (/lib64/libglib-2.0.so.0+0x5249d) ??:? #2 0x5604852f85ca (./x86_64-softmmu/qemu-system-x86_64+0x2c3e5ca) /mnt/sdb/qemu/hw/virtio/virtio.c:2333 #3 0x560485356208 (./x86_64-softmmu/qemu-system-x86_64+0x2c9c208) /mnt/sdb/qemu/hw/virtio/vhost-vsock.c:339 #4 0x560485305a17 (./x86_64-softmmu/qemu-system-x86_64+0x2c4ba17) /mnt/sdb/qemu/hw/virtio/virtio.c:3531 #5 0x5604858e6b65 (./x86_64-softmmu/qemu-system-x86_64+0x322cb65) /mnt/sdb/qemu/hw/core/qdev.c:865 #6 0x5604861e6c41 (./x86_64-softmmu/qemu-system-x86_64+0x3b2cc41) /mnt/sdb/qemu/qom/object.c:2102 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-Id: <20200115062535.50644-1-pannengyuan@huawei.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-01-22virtio-scsi: convert to new virtio_delete_queuePan Nengyuan1-3/+3
Use virtio_delete_queue to make it more clear. Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-Id: <20200117075547.60864-3-pannengyuan@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-01-22virtio-scsi: delete vqs in unrealize to avoid memleaksPan Nengyuan1-0/+6
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> Message-Id: <20200117075547.60864-2-pannengyuan@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-01-22virtio-9p-device: convert to new virtio_delete_queuePan Nengyuan1-1/+1
Use virtio_delete_queue to make it more clear. Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-Id: <20200117060927.51996-3-pannengyuan@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
2020-01-22virtio-9p-device: fix memleak in virtio_9p_device_unrealizePan Nengyuan1-0/+1
v->vq forgot to cleanup in virtio_9p_device_unrealize, the memory leak stack is as follow: Direct leak of 14336 byte(s) in 2 object(s) allocated from: #0 0x7f819ae43970 (/lib64/libasan.so.5+0xef970) ??:? #1 0x7f819872f49d (/lib64/libglib-2.0.so.0+0x5249d) ??:? #2 0x55a3a58da624 (./x86_64-softmmu/qemu-system-x86_64+0x2c14624) /mnt/sdb/qemu/hw/virtio/virtio.c:2327 #3 0x55a3a571bac7 (./x86_64-softmmu/qemu-system-x86_64+0x2a55ac7) /mnt/sdb/qemu/hw/9pfs/virtio-9p-device.c:209 #4 0x55a3a58e7bc6 (./x86_64-softmmu/qemu-system-x86_64+0x2c21bc6) /mnt/sdb/qemu/hw/virtio/virtio.c:3504 #5 0x55a3a5ebfb37 (./x86_64-softmmu/qemu-system-x86_64+0x31f9b37) /mnt/sdb/qemu/hw/core/qdev.c:876 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-Id: <20200117060927.51996-2-pannengyuan@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Acked-by: Greg Kurz <groug@kaod.org>
2020-01-22acpi: cpuhp: add CPHP_GET_CPU_ID_CMD commandIgor Mammedov1-0/+7
Firmware can enumerate present at boot APs by broadcasting wakeup IPI, so that woken up secondary CPUs could register them-selves. However in CPU hotplug case, it would need to know architecture specific CPU IDs for possible and hotplugged CPUs so it could prepare environment for and wake hotplugged AP. Reuse and extend existing CPU hotplug interface to return architecture specific ID for currently selected CPU in 2 registers: - lower 32 bits in ACPI_CPU_CMD_DATA_OFFSET_RW - upper 32 bits in ACPI_CPU_CMD_DATA2_OFFSET_R On x86, firmware will use CPHP_GET_CPU_ID_CMD for fetching the APIC ID when handling hotplug SMI. Later, CPHP_GET_CPU_ID_CMD will be used on ARM to retrieve MPIDR, which serves the similar to APIC ID purpose. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1575896942-331151-10-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-01-22acpi: cpuhp: introduce 'Command data 2' fieldIgor Mammedov2-0/+12
No functional change in practice, patch only aims to properly document (in spec and code) intended usage of the reserved space. The new field is to be used for 2 purposes: - detection of modern CPU hotplug interface using CPHP_GET_NEXT_CPU_WITH_EVENT_CMD command. procedure will be described in follow up patch: "acpi: cpuhp: spec: add typical usecases" - for returning upper 32 bits of architecture specific CPU ID, for new CPHP_GET_CPU_ID_CMD command added by follow up patch: "acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command" Change is backward compatible with 4.2 and older machines, as field was unconditionally reserved and always returned 0x0 if modern CPU hotplug interface was enabled. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1575896942-331151-8-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-01-22q35: implement 128K SMRAM at default SMBASE addressIgor Mammedov2-8/+80
It's not what real HW does, implementing which would be overkill [**] and would require complex cross stack changes (QEMU+firmware) to make it work. So considering that SMRAM is owned by MCH, for simplicity (ab)use reserved Q35 register, which allows QEMU and firmware easily init and make RAM at SMBASE available only from SMM context. Patch uses commit (2f295167e0 q35/mch: implement extended TSEG sizes) for inspiration and uses reserved register in config space at 0x9c offset [*] to extend q35 pci-host with ability to use 128K at 0x30000 as SMRAM and hide it (like TSEG) from non-SMM context. Usage: 1: write 0xff in the register 2: if the feature is supported, follow up read from the register should return 0x01. At this point RAM at 0x30000 is still available for SMI handler configuration from non-SMM context 3: writing 0x02 in the register, locks SMBASE area, making its contents available only from SMM context. In non-SMM context, reads return 0xff and writes are ignored. Further writes into the register are ignored until the system reset. *) https://www.mail-archive.com/qemu-devel@nongnu.org/msg455991.html **) https://www.mail-archive.com/qemu-devel@nongnu.org/msg646965.html Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1575896942-331151-3-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2020-01-209pfs/9p.c: remove unneeded labelsDaniel Henrique Barboza1-6/+3
'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-209p: init_in_iov_from_pdu can truncate the sizeGreg Kurz4-21/+38
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 Barboza1-8/+6
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 Chen1-1/+1
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-20apic: Use 32bit APIC ID for migration instance IDPeter Xu1-1/+4
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 Xu1-1/+1
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 Xu12-12/+17
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-17arm/gicv3: update virtual irq state after IAR register readJeff Kubascik1-0/+3
The IAR0/IAR1 register is used to acknowledge an interrupt - a read of the register activates the highest priority pending interrupt and provides its interrupt ID. Activating an interrupt can change the CPU's virtual interrupt state - this change makes sure the virtual irq state is updated. Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200113154607.97032-1-jeff.kubascik@dornerworks.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-17i.MX: add an emulation for RNGCMartin Kaiser3-0/+290
Add an emulation for the RNGC random number generator and the compatible RNGB variant. These peripherals are included (at least) in imx25 and imx35 chipsets. The emulation supports the initial self test, reseeding the prng and reading random numbers. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-17hw/arm/allwinner-a10: Remove local qemu_irq variablesPhilippe Mathieu-Daudé1-5/+4
We won't reuse the CPU IRQ/FIQ variables. Simplify by calling qdev_get_gpio_in() in place. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20191230110953.25496-6-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-17hw/arm/allwinner-a10: Simplify by passing IRQs with qdev_pass_gpios()Philippe Mathieu-Daudé1-13/+11
By calling qdev_pass_gpios() we don't need to hold a copy of the IRQs from the INTC into the SoC state. Instead of filling an array of qemu_irq and passing it around, we can now directly call qdev_get_gpio_in() on the SoC. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20191230110953.25496-5-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-17hw/arm/allwinner-a10: Move SoC definitions out of headerPhilippe Mathieu-Daudé1-0/+6
These definitions are specific to the A10 SoC and don't need to be exported to the different Allwinner peripherals. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20191230110953.25496-4-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-17hw/arm: Add the Netduino Plus 2Alistair Francis2-0/+53
Signed-off-by: Alistair Francis <alistair@alistair23.me> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: dad8d8d47f7625913e35e27a1c00f603a6b08f9a.1576658572.git.alistair@alistair23.me Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-17hw/arm: Add the STM32F4xx SoCAlistair Francis2-0/+303
Signed-off-by: Alistair Francis <alistair@alistair23.me> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1d145c4c13e5fa140caf131232a6f524c88fcd72.1576658572.git.alistair@alistair23.me Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-17hw/misc: Add the STM32F4xx EXTI deviceAlistair Francis5-0/+198
Signed-off-by: Alistair Francis <alistair@alistair23.me> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: ef941d59fd8658589d34ed432e1d6dfdcf7fb1d0.1576658572.git.alistair@alistair23.me Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-17hw/misc: Add the STM32F4xx Sysconfig deviceAlistair Francis5-0/+190
Signed-off-by: Alistair Francis <alistair@alistair23.me> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 49b01423a09cef2ca832ff73a84a996568f1a8fc.1576658572.git.alistair@alistair23.me Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-16riscv/sifive_u: fix a memory leak in soc_realize()Pan Nengyuan1-0/+1
Fix a minor memory leak in riscv_sifive_u_soc_realize() Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-01-13Merge remote-tracking branch 'remotes/kraxel/tags/usb-20200113-pull-request' ↵Peter Maydell5-3/+65
into staging usb: bugfixes for xhci, usb pass-through and usb redirection. # gpg: Signature made Mon 13 Jan 2020 13:06:35 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/usb-20200113-pull-request: xhci: recheck slot status xhci: Fix memory leak in xhci_kick_epctx when poweroff GuestOS usbredir: Prevent recursion in usbredir_write usb-redir: remove 'remote wakeup' flag from configuration descriptor usb-host: remove 'remote wakeup' flag from configuration descriptor Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-13xhci: recheck slot statusGerd Hoffmann1-3/+12
Factor out slot status check into a helper function. Add an additional check after completing transfers. This is needed in case a guest queues multiple transfers in a row and a device unplug happens while qemu processes them. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1786413 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200107083606.12393-1-kraxel@redhat.com
2020-01-13xhci: Fix memory leak in xhci_kick_epctx when poweroff GuestOSChen Qun1-0/+1
start vm with libvirt, when GuestOS running, enter poweroff command using the xhci keyboard, then ASAN shows memory leak stack: Direct leak of 80 byte(s) in 5 object(s) allocated from: #0 0xfffd1e6431cb in __interceptor_malloc (/lib64/libasan.so.4+0xd31cb) #1 0xfffd1e107163 in g_malloc (/lib64/libglib-2.0.so.0+0x57163) #2 0xaaad39051367 in qemu_sglist_init /qemu/dma-helpers.c:43 #3 0xaaad3947c407 in pci_dma_sglist_init /qemu/include/hw/pci/pci.h:842 #4 0xaaad3947c407 in xhci_xfer_create_sgl /qemu/hw/usb/hcd-xhci.c:1446 #5 0xaaad3947c407 in xhci_setup_packet /qemu/hw/usb/hcd-xhci.c:1618 #6 0xaaad3948625f in xhci_submit /qemu/hw/usb/hcd-xhci.c:1827 #7 0xaaad3948625f in xhci_fire_transfer /qemu/hw/usb/hcd-xhci.c:1839 #8 0xaaad3948625f in xhci_kick_epctx /qemu/hw/usb/hcd-xhci.c:1991 #9 0xaaad3948f537 in xhci_doorbell_write /qemu/hw/usb/hcd-xhci.c:3158 #10 0xaaad38bcbfc7 in memory_region_write_accessor /qemu/memory.c:483 #11 0xaaad38bc654f in access_with_adjusted_size /qemu/memory.c:544 #12 0xaaad38bd1877 in memory_region_dispatch_write /qemu/memory.c:1482 #13 0xaaad38b1c77f in flatview_write_continue /qemu/exec.c:3167 #14 0xaaad38b1ca83 in flatview_write /qemu/exec.c:3207 #15 0xaaad38b268db in address_space_write /qemu/exec.c:3297 #16 0xaaad38bf909b in kvm_cpu_exec /qemu/accel/kvm/kvm-all.c:2383 #17 0xaaad38bb063f in qemu_kvm_cpu_thread_fn /qemu/cpus.c:1246 #18 0xaaad39821c93 in qemu_thread_start /qemu/util/qemu-thread-posix.c:519 #19 0xfffd1c8378bb (/lib64/libpthread.so.0+0x78bb) #20 0xfffd1c77616b (/lib64/libc.so.6+0xd616b) Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com> Message-id: 20200110105855.81144-1-kuhn.chenqun@huawei.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-01-13usbredir: Prevent recursion in usbredir_writeDr. David Alan Gilbert1-0/+9
I've got a case where usbredir_write manages to call back into itself via spice; this patch causes the recursion to fail (0 bytes) the write; this seems to avoid the deadlock I was previously seeing. I can't say I fully understand the interaction of usbredir and spice; but there are a few similar guards in spice and usbredir to catch other cases especially onces also related to spice_server_char_device_wakeup This case seems to be triggered by repeated migration+repeated reconnection of the viewer; but my debugging suggests the migration finished before this hits. The backtrace of the hang looks like: reds_handle_ticket reds_handle_other_links reds_channel_do_link red_channel_connect spicevmc_connect usbredir_create_parser usbredirparser_do_write usbredir_write qemu_chr_fe_write qemu_chr_write qemu_chr_write_buffer spice_chr_write spice_server_char_device_wakeup red_char_device_wakeup red_char_device_write_to_device vmc_write usbredirparser_do_write usbredir_write qemu_chr_fe_write qemu_chr_write qemu_chr_write_buffer qemu_mutex_lock_impl and we fail as we lang through qemu_chr_write_buffer's lock twice. Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1752320 Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20191218113012.13331-1-dgilbert@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-01-13usb-redir: remove 'remote wakeup' flag from configuration descriptorYuri Benditovich2-0/+21
If the redirected device has this capability, Windows guest may place the device into D2 and expect it to wake when the device becomes active, but this will never happen. For example, when internal Bluetooth adapter is redirected, keyboards and mice connected to it do not work. Current commit removes this capability (starting from machine 5.0) Set 'usb-redir.suppress-remote-wake' property to 'off' to keep 'remote wake' as is or to 'on' to remove 'remote wake' on 4.2 or earlier. Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com> Message-id: 20200108091044.18055-3-yuri.benditovich@daynix.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-01-13usb-host: remove 'remote wakeup' flag from configuration descriptorYuri Benditovich3-0/+22
If the redirected device has this capability, Windows guest may place the device into D2 and expect it to wake when the device becomes active, but this will never happen. For example, when internal Bluetooth adapter is redirected, keyboards and mice connected to it do not work. Current commit removes this capability (starting from machine 5.0) Set 'usb-host.suppress-remote-wake' property to 'off' to keep 'remote wake' as is or to 'on' to remove 'remote wake' on 4.2 or earlier. Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com> Message-id: 20200108091044.18055-2-yuri.benditovich@daynix.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-01-10Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell44-46/+114
* Compat machines fix (Denis) * Command line parsing fixes (Michal, Peter, Xiaoyao) * Cooperlake CPU model fixes (Xiaoyao) * i386 gdb fix (mkdolata) * IOEventHandler cleanup (Philippe) * icount fix (Pavel) * RR support for random number sources (Pavel) * Kconfig fixes (Philippe) # gpg: Signature made Wed 08 Jan 2020 10:41:00 GMT # gpg: using RSA key BFFBD25F78C7AE83 # 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: (38 commits) chardev: Use QEMUChrEvent enum in IOEventHandler typedef chardev: use QEMUChrEvent instead of int chardev/char: Explicit we ignore some QEMUChrEvent in IOEventHandler monitor/hmp: Explicit we ignore a QEMUChrEvent in IOEventHandler monitor/qmp: Explicit we ignore few QEMUChrEvent in IOEventHandler virtio-console: Explicit we ignore some QEMUChrEvent in IOEventHandler vhost-user-blk: Explicit we ignore few QEMUChrEvent in IOEventHandler vhost-user-net: Explicit we ignore few QEMUChrEvent in IOEventHandler vhost-user-crypto: Explicit we ignore some QEMUChrEvent in IOEventHandler ccid-card-passthru: Explicit we ignore QEMUChrEvent in IOEventHandler hw/usb/redirect: Explicit we ignore few QEMUChrEvent in IOEventHandler hw/usb/dev-serial: Explicit we ignore few QEMUChrEvent in IOEventHandler hw/char/terminal3270: Explicit ignored QEMUChrEvent in IOEventHandler hw/ipmi: Explicit we ignore some QEMUChrEvent in IOEventHandler hw/ipmi: Remove unnecessary declarations target/i386: Add missed features to Cooperlake CPU model target/i386: Add new bit definitions of MSR_IA32_ARCH_CAPABILITIES target/i386: Fix handling of k_gs_base register in 32-bit mode in gdbstub hw/rtc/mc146818: Add missing dependency on ISA Bus hw/nvram/Kconfig: Restrict CHRP NVRAM to machines using OpenBIOS or SLOF ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-10Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-5.0-20200108' ↵Peter Maydell12-141/+154
into staging ppc patch queue 2020-01-08 Here's another pull request for qemu-5.0 of ppc related changes. Highlights are: * First parts of support for POWER Secure VMs * Rework to clean up how we pass context information to the various components of the pnv machine (reduces usage of qdev_get_machine()) * Assorted cleanups and bugfixes # gpg: Signature made Wed 08 Jan 2020 05:22:08 GMT # gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full] # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full] # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full] # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown] # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-5.0-20200108: (26 commits) ppc/pnv: fix check on return value of blk_getlength() ppc/pnv: check return value of blk_pwrite() pnv/psi: Consolidate some duplicated code in pnv_psi_realize() pnv/psi: Add device reset hook pnv/xive: Deduce the PnvXive pointer from XiveTCTX::xptr spapr/xive: Deduce the SpaprXive pointer from XiveTCTX::xptr xive: Add a "presenter" link property to the TCTX object ppc/pnv: Add a "pnor" const link property to the BMC internal simulator ppc/pnv: Add an "nr-threads" property to the base chip class xive: Use the XIVE fabric link under the XIVE router spapr, pnv, xive: Add a "xive-fabric" link to the XIVE router pnv/xive: Use device_class_set_parent_realize() ppc/pnv: Introduce a "xics" property under the POWER8 chip ppc/pnv: Introduce a "xics" property alias under the PSI model spapr/xive: remove redundant check in spapr_match_nvt() ppc/pnv: Drop "num-chips" machine property ppc440_bamboo.c: remove label from bamboo_load_device_tree() spapr.c: remove 'out' label in spapr_dt_cas_updates() ppc/spapr: Don't call KVM_SVM_OFF ioctl on TCG spapr/xive: Use device_class_set_parent_realize() ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>