aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)Author
2020-03-03dp8393x: Don't clobber packet checksumFinn Thain
A received packet consumes pkt_size bytes in the buffer and the frame checksum that's appended to it consumes another 4 bytes. The Receive Buffer Address register takes the former quantity into account but not the latter. So the next packet written to the buffer overwrites the frame checksum. Fix this. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-03-03dp8393x: Implement packet size limit and RBAE interruptFinn Thain
Add a bounds check to prevent a large packet from causing a buffer overflow. This is defensive programming -- I haven't actually tried sending an oversized packet or a jumbo ethernet frame. The SONIC handles packets that are too big for the buffer by raising the RBAE interrupt and dropping them. Linux uses that interrupt to count dropped packets. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-03-03dp8393x: Clear RRRA command register bit only when appropriateFinn Thain
It doesn't make sense to clear the command register bit unless the command was actually issued. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-03-03dp8393x: Update LLFA and CRDA registers from rx descriptorFinn Thain
Follow the algorithm given in the National Semiconductor DP83932C datasheet in section 3.4.7: At the next reception, the SONIC re-reads the last RXpkt.link field, and updates its CRDA register to point to the next descriptor. The chip is designed to allow the host to provide a new list of descriptors in this way. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-03-03dp8393x: Have dp8393x_receive() return the packet sizeFinn Thain
This function re-uses its 'size' argument as a scratch variable. Instead, declare a local 'size' variable for that purpose so that the function result doesn't get messed up. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-03-03dp8393x: Clean up endianness hacksFinn Thain
According to the datasheet, section 3.4.4, "in 32-bit mode ... the SONIC always writes long words". Therefore, use the same technique for the 'in_use' field that is used everywhere else, and write the full long word. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-03-03dp8393x: Always use 32-bit accessesFinn Thain
The DP83932 and DP83934 have 32 data lines. The datasheet says, Data Bus: These bidirectional lines are used to transfer data on the system bus. When the SONIC is a bus master, 16-bit data is transferred on D15-D0 and 32-bit data is transferred on D31-D0. When the SONIC is accessed as a slave, register data is driven onto lines D15-D0. D31-D16 are held TRI-STATE if SONIC is in 16-bit mode. If SONIC is in 32-bit mode, they are driven, but invalid. Always use 32-bit accesses both as bus master and bus slave. Force the MSW to zero in bus master mode. This gets the Linux 'jazzsonic' driver working, and avoids the need for prior hacks to make the NetBSD 'sn' driver work. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-03-02dp8393x: Mask EOL bit from descriptor addressesFinn Thain
The Least Significant bit of a descriptor address register is used as an EOL flag. It has to be masked when the register value is to be used as an actual address for copying memory around. But when the registers are to be updated the EOL bit should not be masked. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-02-28hw/intc/arm_gic_kvm: Don't assume kernel can provide a GICv2Peter Maydell
In our KVM GICv2 realize function, we try to cope with old kernels that don't provide the device control API (KVM_CAP_DEVICE_CTRL): we try to use the device control, and if that fails we fall back to assuming that the kernel has the old style KVM_CREATE_IRQCHIP and that it will provide a GICv2. This doesn't cater for the possibility of a kernel and hardware which only provide a GICv3, which is very common now. On that setup we will abort() later on in kvm_arm_pmu_set_irq() when we try to wire up an interrupt to the GIC we failed to create: qemu-system-aarch64: PMU: KVM_SET_DEVICE_ATTR: Invalid argument qemu-system-aarch64: failed to set irq for PMU Aborted If the kernel advertises KVM_CAP_DEVICE_CTRL we should trust it if it says it can't create a GICv2, rather than assuming it has one. We can then produce a more helpful error message including a hint about the most probable reason for the failure. If the kernel doesn't advertise KVM_CAP_DEVICE_CTRL then it is truly ancient by this point but we might as well still fall back to a KVM_CREATE_IRQCHIP GICv2. With this patch then the user misconfiguration which previously caused an abort now prints: qemu-system-aarch64: Initialization of device kvm-arm-gic failed: error creating in-kernel VGIC: No such device Perhaps the host CPU does not support GICv2? Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Tested-by: Andrew Jones <drjones@redhat.com> Message-id: 20200225182435.1131-1-peter.maydell@linaro.org
2020-02-28hw/usb/hcd-ehci-sysbus: Remove obsolete xlnx, ps7-usb classGuenter Roeck
Xilinx USB devices are now instantiated through TYPE_CHIPIDEA, and xlnx support in the EHCI code is no longer needed. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200215122354.13706-3-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-28hw/arm/xilinx_zynq: Fix USB port instantiationGuenter Roeck
USB ports on Xilinx Zync must be instantiated as TYPE_CHIPIDEA to work. Linux expects and checks various chipidea registers, which do not exist with the basic ehci emulation. This patch series fixes the problem. Without this patch, USB ports fail to instantiate under Linux. ci_hdrc ci_hdrc.0: doesn't support host ci_hdrc ci_hdrc.0: no supported roles With this patch, USB ports are instantiated, and it is possible to boot from USB drive. ci_hdrc ci_hdrc.0: EHCI Host Controller ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 usb 1-1: new full-speed USB device number 2 using ci_hdrc usb 1-1: not running at top speed; connect to a high speed hub usb 1-1: config 1 interface 0 altsetting 0 endpoint 0x81 has invalid maxpacket 512, setting to 64 usb 1-1: config 1 interface 0 altsetting 0 endpoint 0x2 has invalid maxpacket 512, setting to 64 usb-storage 1-1:1.0: USB Mass Storage device detected scsi host0: usb-storage 1-1:1.0 Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200215122354.13706-2-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-28target/arm: Add isar_feature_aa32_vfp_simdRichard Henderson
Use this in the places that were checking ARM_FEATURE_VFP, and are obviously testing for the existance of the register set as opposed to testing for some particular instruction extension. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200224222232.13807-2-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-28cpu/arm11mpcore: Set number of GIC priority bits to 4Sai Pavan Boddu
The GIC built into the ARM11MPCore is always implemented with 4 priority bits; set the GIC property accordingly. Signed-off-by: Sai Pavan Boddu <sai.pavan.boddu@xilinx.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1582537164-764-4-git-send-email-sai.pavan.boddu@xilinx.com Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: tweaked commit message] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-28cpu/a9mpcore: Set number of GIC priority bits to 5Sai Pavan Boddu
All A9 CPUs have a GIC with 5 bits of priority. Signed-off-by: Sai Pavan Boddu <sai.pavan.boddu@xilinx.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1582537164-764-3-git-send-email-sai.pavan.boddu@xilinx.com Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-28arm_gic: Mask the un-supported priority bitsSai Pavan Boddu
The GICv2 allows the implementation to implement a variable number of priority bits; unimplemented bits in the priority registers are read as zeros, writes ignored. We were previously always implementing a full 8 bits of priority, which is allowed but not what the real hardware typically does (which is usually to have 4 or 5 bits of priority). Add a new device property to allow the number of implemented property bits to be specified. Signed-off-by: Sai Pavan Boddu <sai.pavan.boddu@xilinx.com> Message-id: 1582537164-764-2-git-send-email-sai.pavan.boddu@xilinx.com Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: improved commit message] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-28hw/arm/integratorcp: Map the audio codec controllerPhilippe Mathieu-Daudé
The Linux kernel displays errors why trying to detect the PL041 audio interface: Linux version 4.16.0 (linus@genomnajs) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #142 PREEMPT Wed May 9 13:24:55 CEST 2018 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00093177 CPU: VIVT data cache, VIVT instruction cache OF: fdt: Machine model: ARM Integrator/CP ... OF: amba_device_add() failed (-19) for /fpga/aaci@1d000000 Since we have it already modelled, simply plug it. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200223233033.15371-2-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-28hw/arm: Use TYPE_PL011 to create serial portGavin Shan
This uses TYPE_PL011 when creating the serial port so that the code looks cleaner. Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200224222223.4128-1-gshan@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-28Merge remote-tracking branch ↵Peter Maydell
'remotes/juanquintela/tags/pull-migration-pull-request' into staging Migration pull request # gpg: Signature made Fri 28 Feb 2020 09:21:31 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/pull-migration-pull-request: savevm: Don't call colo_init_ram_cache twice migration/colo: wrap incoming checkpoint process into new helper migration: fix COLO broken caused by a previous commit migration/block: rename BLOCK_SIZE macro migration/savevm: release gslist after dump_vmstate_json test-vmstate: Fix memleaks in test_load_qlist migration/vmstate: Remove redundant statement in vmstate_save_state_v() multifd: Add zstd compression multifd support multifd: Add multifd-zstd-level parameter configure: Enable test and libs for zstd multifd: Add zlib compression multifd support multifd: Add multifd-zlib-level parameter multifd: Make no compression operations into its own structure migration: Add support for modules multifd: Add multifd-compression parameter Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-28Merge remote-tracking branch 'remotes/amarkovic/tags/mips-queue-feb-27-2020' ↵Peter Maydell
into staging MIPS queue for February 27th, 2020 # gpg: Signature made Thu 27 Feb 2020 13:20:55 GMT # gpg: using RSA key D4972A8967F75A65 # gpg: Good signature from "Aleksandar Markovic <amarkovic@wavecomp.com>" [full] # Primary key fingerprint: 8526 FBF1 5DA3 811F 4A01 DD75 D497 2A89 67F7 5A65 * remotes/amarkovic/tags/mips-queue-feb-27-2020: tests/acceptance: Count multiple Tux logos displayed on framebuffer hw/mips: Use memory_region_init_rom() with read-only regions hw/mips/mips_int: Simplify cpu_mips_irq_init_cpu() MAINTAINERS: Reactivate MIPS KVM CPUs MAINTAINERS: Orphan MIPS KVM CPUs Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-28Merge remote-tracking branch 'remotes/aperard/tags/pull-xen-20200227' into ↵Peter Maydell
staging Xen queue 2020-02-27 * fix for xen-block * fix in exec.c for migration of xen guest * one cleanup patch # gpg: Signature made Thu 27 Feb 2020 11:57:12 GMT # gpg: using RSA key F80C006308E22CFD8A92E7980CF5572FD7FB55AF # gpg: issuer "anthony.perard@citrix.com" # gpg: Good signature from "Anthony PERARD <anthony.perard@gmail.com>" [marginal] # gpg: aka "Anthony PERARD <anthony.perard@citrix.com>" [marginal] # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: 5379 2F71 024C 600F 778A 7161 D8D5 7199 DF83 42C8 # Subkey fingerprint: F80C 0063 08E2 2CFD 8A92 E798 0CF5 572F D7FB 55AF * remotes/aperard/tags/pull-xen-20200227: Memory: Only call ramblock_ptr when needed in qemu_ram_writeback xen-bus/block: explicitly assign event channels to an AioContext hw/xen/xen_pt_load_rom: Remove unused includes Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-28multifd: Add zstd compression multifd supportJuan Quintela
Signed-off-by: Juan Quintela <quintela@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-02-28multifd: Add zlib compression multifd supportJuan Quintela
Signed-off-by: Juan Quintela <quintela@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-02-28multifd: Add multifd-compression parameterJuan Quintela
This will store the compression method to use. We start with none. Signed-off-by: Juan Quintela <quintela@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> --- Rename multifd-method to multifd-compression
2020-02-27Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20200227' into stagingPeter Maydell
Includes a headers update against 5.6-current. - add missing vcpu reset functionality - rstfy some s390 documentation - fixes and enhancements # gpg: Signature made Thu 27 Feb 2020 11:50:08 GMT # gpg: using RSA key C3D0D66DC3624FF6A8C018CEDECF6B93C6F02FAF # gpg: issuer "cohuck@redhat.com" # gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>" [marginal] # gpg: aka "Cornelia Huck <huckc@linux.vnet.ibm.com>" [full] # gpg: aka "Cornelia Huck <cornelia.huck@de.ibm.com>" [full] # gpg: aka "Cornelia Huck <cohuck@kernel.org>" [marginal] # gpg: aka "Cornelia Huck <cohuck@redhat.com>" [marginal] # Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0 18CE DECF 6B93 C6F0 2FAF * remotes/cohuck/tags/s390x-20200227: s390x: Rename and use constants for short PSW address and mask docs: rstfy vfio-ap documentation docs: rstfy s390 dasd ipl documentation s390/sclp: improve special wait psw logic s390x: Add missing vcpu reset functions linux-headers: update target/s390x/translate: Fix RNSBG instruction Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-27Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell
virtio, pc: fixes, features New virtio iommu. Unrealize memory leaks. In-band kick/call support. Bugfixes, documentation all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Thu 27 Feb 2020 08:46:33 GMT # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full] # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * remotes/mst/tags/for_upstream: (30 commits) Fixed assert in vhost_user_set_mem_table_postcopy vhost-user: only set slave channel for first vq acpi: cpuhp: document CPHP_GET_CPU_ID_CMD command libvhost-user: implement in-band notifications docs: vhost-user: add in-band kick/call messages libvhost-user: handle NOFD flag in call/kick/err better libvhost-user-glib: use g_main_context_get_thread_default() libvhost-user-glib: fix VugDev main fd cleanup libvhost-user: implement VHOST_USER_PROTOCOL_F_REPLY_ACK MAINTAINERS: add virtio-iommu related files hw/arm/virt: Add the virtio-iommu device tree mappings virtio-iommu-pci: Add virtio iommu pci support virtio-iommu: Support migration virtio-iommu: Implement fault reporting virtio-iommu: Implement translate virtio-iommu: Implement map/unmap virtio-iommu: Implement attach/detach command virtio-iommu: Decode the command payload virtio-iommu: Add skeleton virtio: gracefully handle invalid region caches ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-27hw/mips: Use memory_region_init_rom() with read-only regionsPhilippe Mathieu-Daudé
This commit was produced with the Coccinelle script scripts/coccinelle/memory-region-housekeeping.cocci. Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <20200224205533.23798-8-philmd@redhat.com>
2020-02-27hw/mips/mips_int: Simplify cpu_mips_irq_init_cpu()Philippe Mathieu-Daudé
Since commit d8ed887bdc, the cpu_mips_irq_request handler takes a pointer to MIPSCPU in its opaque argument. Directly pass the cpu pointer. Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <20200221162011.26383-1-philmd@redhat.com>
2020-02-27xen-bus/block: explicitly assign event channels to an AioContextPaul Durrant
It is not safe to close an event channel from the QEMU main thread when that channel's poller is running in IOThread context. This patch adds a new xen_device_set_event_channel_context() function to explicitly assign the channel AioContext, and modifies xen_device_bind_event_channel() to initially assign the channel's poller to the QEMU main thread context. The code in xen-block's dataplane is then modified to assign the channel to IOThread context during xen_block_dataplane_start() and de-assign it during in xen_block_dataplane_stop(), such that the channel is always assigned back to main thread context before it is closed. aio_set_fd_handler() already deals with all the necessary synchronization when moving an fd between AioContext-s so no extra code is needed to manage this. Reported-by: Julien Grall <jgrall@amazon.com> Signed-off-by: Paul Durrant <pdurrant@amazon.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20191216143451.19024-1-pdurrant@amazon.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2020-02-27hw/xen/xen_pt_load_rom: Remove unused includesPhilippe Mathieu-Daudé
xen_pt_load_rom.c does not use any of these includes, remove them. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <20191014142246.4538-9-philmd@redhat.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2020-02-27s390x: Rename and use constants for short PSW address and maskJanosch Frank
Let's rename PSW_MASK_ESA_ADDR to PSW_MASK_SHORT_ADDR because we're not working with a ESA PSW which would not support the extended addressing bit. Also let's actually use it. Additionally we introduce PSW_MASK_SHORT_CTRL and use it throughout the codebase. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20200227092341.38558-1-frankja@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-02-27Fixed assert in vhost_user_set_mem_table_postcopyRaphael Norwitz
The current vhost_user_set_mem_table_postcopy() implementation populates each region of the VHOST_USER_SET_MEM_TABLE message without first checking if there are more than VHOST_MEMORY_MAX_NREGIONS already populated. This can cause memory corruption if too many regions are added to the message during the postcopy step. This change moves an existing assert up such that attempting to construct a VHOST_USER_SET_MEM_TABLE message with too many memory regions will gracefully bring down qemu instead of corrupting memory. Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by: Peter Turschmid <peter.turschm@nutanix.com> Message-Id: <1579143426-18305-2-git-send-email-raphael.norwitz@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-27vhost-user: only set slave channel for first vqAdrian Moreno
When multiqueue is enabled, a vhost_dev is created for each queue pair. However, only one slave channel is needed. Fixes: 4bbeeba023f2 (vhost-user: add slave-req-fd support) Cc: marcandre.lureau@redhat.com Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Message-Id: <20200121214553.28459-1-amorenoz@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-27hw/arm/virt: Add the virtio-iommu device tree mappingsEric Auger
Adds the "virtio,pci-iommu" node in the host bridge node and the RID mapping, excluding the IOMMU RID. This is done in the virtio-iommu-pci hotplug handler which gets called only if no firmware is loaded or if -no-acpi is passed on the command line. As non DT integration is not yet supported by the kernel we must make sure we are in DT mode. This limitation will be removed as soon as the topology description feature gets supported. Signed-off-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20200214132745.23392-10-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-27virtio-iommu-pci: Add virtio iommu pci supportEric Auger
This patch adds virtio-iommu-pci, which is the pci proxy for the virtio-iommu device. Currently non DT integration is not yet supported by the kernel. So the machine must implement a hotplug handler for the virtio-iommu-pci device that creates the device tree iommu-map bindings as documented in kernel documentation: Documentation/devicetree/bindings/virtio/iommu.txt Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20200214132745.23392-9-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-27virtio-iommu: Support migrationEric Auger
Add Migration support. We rely on recently added gtree and qlist migration. We only migrate the domain gtree. The endpoint gtree is re-constructed in a post-load operation. Signed-off-by: Eric Auger <eric.auger@redhat.com> Acked-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20200214132745.23392-8-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-27virtio-iommu: Implement fault reportingEric Auger
The event queue allows to report asynchronous errors. The translate function now injects faults when relevant. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20200214132745.23392-7-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-27virtio-iommu: Implement translateEric Auger
This patch implements the translate callback Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20200214132745.23392-6-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-27virtio-iommu: Implement map/unmapEric Auger
This patch implements virtio_iommu_map/unmap. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20200214132745.23392-5-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-27virtio-iommu: Implement attach/detach commandEric Auger
This patch implements the endpoint attach/detach to/from a domain. Domain and endpoint internal datatypes are introduced. Both are stored in RB trees. The domain owns a list of endpoints attached to it. Also helpers to get/put end points and domains are introduced. As for the IOMMU memory regions, a callback is called on PCI bus enumeration that initializes for a given device on the bus hierarchy an IOMMU memory region. The PCI bus hierarchy is stored locally in IOMMUPciBus and IOMMUDevice objects. At the time of the enumeration, the bus number may not be computed yet. So operations that will need to retrieve the IOMMUdevice and its IOMMU memory region from the bus number and devfn, once the bus number is garanteed to be frozen, use an array of IOMMUPciBus, lazily populated. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20200214132745.23392-4-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-27virtio-iommu: Decode the command payloadEric Auger
This patch adds the command payload decoding and introduces the functions that will do the actual command handling. Those functions are not yet implemented. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20200214132745.23392-3-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-27virtio-iommu: Add skeletonEric Auger
This patchs adds the skeleton for the virtio-iommu device. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20200214132745.23392-2-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-27virtio: gracefully handle invalid region cachesStefan Hajnoczi
The virtqueue code sets up MemoryRegionCaches to access the virtqueue guest RAM data structures. The code currently assumes that VRingMemoryRegionCaches is initialized before device emulation code accesses the virtqueue. An assertion will fail in vring_get_region_caches() when this is not true. Device fuzzing found a case where this assumption is false (see below). Virtqueue guest RAM addresses can also be changed from a vCPU thread while an IOThread is accessing the virtqueue. This breaks the same assumption but this time the caches could become invalid partway through the virtqueue code. The code fetches the caches RCU pointer multiple times so we will need to validate the pointer every time it is fetched. Add checks each time we call vring_get_region_caches() and treat invalid caches as a nop: memory stores are ignored and memory reads return 0. The fuzz test failure is as follows: $ qemu -M pc -device virtio-blk-pci,id=drv0,drive=drive0,addr=4.0 \ -drive if=none,id=drive0,file=null-co://,format=raw,auto-read-only=off \ -drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw \ -display none \ -qtest stdio endianness outl 0xcf8 0x80002020 outl 0xcfc 0xe0000000 outl 0xcf8 0x80002004 outw 0xcfc 0x7 write 0xe0000000 0x24 0x00ffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffab5cffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffab0000000001 inb 0x4 writew 0xe000001c 0x1 write 0xe0000014 0x1 0x0d The following error message is produced: qemu-system-x86_64: /home/stefanha/qemu/hw/virtio/virtio.c:286: vring_get_region_caches: Assertion `caches != NULL' failed. The backtrace looks like this: #0 0x00007ffff5520625 in raise () at /lib64/libc.so.6 #1 0x00007ffff55098d9 in abort () at /lib64/libc.so.6 #2 0x00007ffff55097a9 in _nl_load_domain.cold () at /lib64/libc.so.6 #3 0x00007ffff5518a66 in annobin_assert.c_end () at /lib64/libc.so.6 #4 0x00005555559073da in vring_get_region_caches (vq=<optimized out>) at qemu/hw/virtio/virtio.c:286 #5 vring_get_region_caches (vq=<optimized out>) at qemu/hw/virtio/virtio.c:283 #6 0x000055555590818d in vring_used_flags_set_bit (mask=1, vq=0x5555575ceea0) at qemu/hw/virtio/virtio.c:398 #7 virtio_queue_split_set_notification (enable=0, vq=0x5555575ceea0) at qemu/hw/virtio/virtio.c:398 #8 virtio_queue_set_notification (vq=vq@entry=0x5555575ceea0, enable=enable@entry=0) at qemu/hw/virtio/virtio.c:451 #9 0x0000555555908512 in virtio_queue_set_notification (vq=vq@entry=0x5555575ceea0, enable=enable@entry=0) at qemu/hw/virtio/virtio.c:444 #10 0x00005555558c697a in virtio_blk_handle_vq (s=0x5555575c57e0, vq=0x5555575ceea0) at qemu/hw/block/virtio-blk.c:775 #11 0x0000555555907836 in virtio_queue_notify_aio_vq (vq=0x5555575ceea0) at qemu/hw/virtio/virtio.c:2244 #12 0x0000555555cb5dd7 in aio_dispatch_handlers (ctx=ctx@entry=0x55555671a420) at util/aio-posix.c:429 #13 0x0000555555cb67a8 in aio_dispatch (ctx=0x55555671a420) at util/aio-posix.c:460 #14 0x0000555555cb307e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at util/async.c:260 #15 0x00007ffff7bbc510 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #16 0x0000555555cb5848 in glib_pollfds_poll () at util/main-loop.c:219 #17 os_host_main_loop_wait (timeout=<optimized out>) at util/main-loop.c:242 #18 main_loop_wait (nonblocking=<optimized out>) at util/main-loop.c:518 #19 0x00005555559b20c9 in main_loop () at vl.c:1683 #20 0x0000555555838115 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4441 Reported-by: Alexander Bulekov <alxndr@bu.edu> Cc: Michael Tsirkin <mst@redhat.com> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200207104619.164892-1-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-25vhost-user-blk: convert to new virtio_delete_queuePan Nengyuan
use the new virtio_delete_queue function to cleanup. Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-Id: <20200224041336.30790-3-pannengyuan@huawei.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-02-25vhost-user-blk: delete virtioqueues in unrealize to fix memleaksPan Nengyuan
virtio queues forgot to delete in unrealize, and aslo error path in realize, this patch fix these memleaks, the leak stack is as follow: Direct leak of 114688 byte(s) in 16 object(s) allocated from: #0 0x7f24024fdbf0 in calloc (/lib64/libasan.so.3+0xcabf0) #1 0x7f2401642015 in g_malloc0 (/lib64/libglib-2.0.so.0+0x50015) #2 0x55ad175a6447 in virtio_add_queue /mnt/sdb/qemu/hw/virtio/virtio.c:2327 #3 0x55ad17570cf9 in vhost_user_blk_device_realize /mnt/sdb/qemu/hw/block/vhost-user-blk.c:419 #4 0x55ad175a3707 in virtio_device_realize /mnt/sdb/qemu/hw/virtio/virtio.c:3509 #5 0x55ad176ad0d1 in device_set_realized /mnt/sdb/qemu/hw/core/qdev.c:876 #6 0x55ad1781ff9d in property_set_bool /mnt/sdb/qemu/qom/object.c:2080 #7 0x55ad178245ae in object_property_set_qobject /mnt/sdb/qemu/qom/qom-qobject.c:26 #8 0x55ad17821eb4 in object_property_set_bool /mnt/sdb/qemu/qom/object.c:1338 #9 0x55ad177aeed7 in virtio_pci_realize /mnt/sdb/qemu/hw/virtio/virtio-pci.c:1801 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: <20200224041336.30790-2-pannengyuan@huawei.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-02-25virtio-crypto: do delete ctrl_vq in virtio_crypto_device_unrealizePan Nengyuan
Similar to other virtio-deivces, ctrl_vq forgot to delete in virtio_crypto_device_unrealize, this patch fix it. This device has aleardy maintained vq pointers. Thus, we use the new virtio_delete_queue function directly to do the cleanup. The leak stack: Direct leak of 10752 byte(s) in 3 object(s) allocated from: #0 0x7f4c024b1970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7f4c018be49d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d) #2 0x55a2f8017279 in virtio_add_queue /mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio.c:2333 #3 0x55a2f8057035 in virtio_crypto_device_realize /mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio-crypto.c:814 #4 0x55a2f8005d80 in virtio_device_realize /mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio.c:3531 #5 0x55a2f8497d1b in device_set_realized /mnt/sdb/qemu-new/qemu_test/qemu/hw/core/qdev.c:891 #6 0x55a2f8b48595 in property_set_bool /mnt/sdb/qemu-new/qemu_test/qemu/qom/object.c:2238 #7 0x55a2f8b54fad in object_property_set_qobject /mnt/sdb/qemu-new/qemu_test/qemu/qom/qom-qobject.c:26 #8 0x55a2f8b4de2c in object_property_set_bool /mnt/sdb/qemu-new/qemu_test/qemu/qom/object.c:1390 #9 0x55a2f80609c9 in virtio_crypto_pci_realize /mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio-crypto-pci.c:58 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Cc: "Gonglei (Arei)" <arei.gonglei@huawei.com> Message-Id: <20200225075554.10835-5-pannengyuan@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-25virtio-pmem: do delete rq_vq in virtio_pmem_unrealizePan Nengyuan
Similar to other virtio-devices, rq_vq forgot to delete in virtio_pmem_unrealize, this patch fix it. This device has already maintained a vq pointer, thus we use the new virtio_delete_queue function directly to do the cleanup. Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-Id: <20200225075554.10835-4-pannengyuan@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-25vhost-user-fs: convert to the new virtio_delete_queue functionPan Nengyuan
use the new virtio_delete_queue function to cleanup. Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200225075554.10835-3-pannengyuan@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-25vhost-user-fs: do delete virtio_queues in unrealizePan Nengyuan
Similar to other virtio device(https://patchwork.kernel.org/patch/11399237/), virtio queues forgot to delete in unrealize, and aslo error path in realize, this patch fix these memleaks, the leak stack is as follow: Direct leak of 57344 byte(s) in 1 object(s) allocated from: #0 0x7f15784fb970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7f157790849d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d) #2 0x55587a1bf859 in virtio_add_queue /mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio.c:2333 #3 0x55587a2071d5 in vuf_device_realize /mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/vhost-user-fs.c:212 #4 0x55587a1ae360 in virtio_device_realize /mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio.c:3531 #5 0x55587a63fb7b in device_set_realized /mnt/sdb/qemu-new/qemu_test/qemu/hw/core/qdev.c:891 #6 0x55587acf03f5 in property_set_bool /mnt/sdb/qemu-new/qemu_test/qemu/qom/object.c:2238 #7 0x55587acfce0d in object_property_set_qobject /mnt/sdb/qemu-new/qemu_test/qemu/qom/qom-qobject.c:26 #8 0x55587acf5c8c in object_property_set_bool /mnt/sdb/qemu-new/qemu_test/qemu/qom/object.c:1390 #9 0x55587a8e22a2 in pci_qdev_realize /mnt/sdb/qemu-new/qemu_test/qemu/hw/pci/pci.c:2095 #10 0x55587a63fb7b in device_set_realized /mnt/sdb/qemu-new/qemu_test/qemu/hw/core/qdev.c:891 #11 0x55587acf03f5 in property_set_bool /mnt/sdb/qemu-new/qemu_test/qemu/qom/object.c:2238 #12 0x55587acfce0d in object_property_set_qobject /mnt/sdb/qemu-new/qemu_test/qemu/qom/qom-qobject.c:26 #13 0x55587acf5c8c in object_property_set_bool /mnt/sdb/qemu-new/qemu_test/qemu/qom/object.c:1390 #14 0x55587a496d65 in qdev_device_add /mnt/sdb/qemu-new/qemu_test/qemu/qdev-monitor.c:679 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200225075554.10835-2-pannengyuan@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-25Merge branch 'exec_rw_const_v4' of https://github.com/philmd/qemu into HEADPaolo Bonzini
2020-02-25Merge tag 'patchew/20200219160953.13771-1-imammedo@redhat.com' of ↵Paolo Bonzini
https://github.com/patchew-project/qemu into HEAD This series removes ad hoc RAM allocation API (memory_region_allocate_system_memory) and consolidates it around hostmem backend. It allows to * resolve conflicts between global -mem-prealloc and hostmem's "policy" option, fixing premature allocation before binding policy is applied * simplify complicated memory allocation routines which had to deal with 2 ways to allocate RAM. * reuse hostmem backends of a choice for main RAM without adding extra CLI options to duplicate hostmem features. A recent case was -mem-shared, to enable vhost-user on targets that don't support hostmem backends [1] (ex: s390) * move RAM allocation from individual boards into generic machine code and provide them with prepared MemoryRegion. * clean up deprecated NUMA features which were tied to the old API (see patches) - "numa: remove deprecated -mem-path fallback to anonymous RAM" - (POSTPONED, waiting on libvirt side) "forbid '-numa node,mem' for 5.0 and newer machine types" - (POSTPONED) "numa: remove deprecated implicit RAM distribution between nodes" Introduce a new machine.memory-backend property and wrapper code that aliases global -mem-path and -mem-alloc into automatically created hostmem backend properties (provided memory-backend was not set explicitly given by user). A bulk of trivial patches then follow to incrementally convert individual boards to using machine.memory-backend provided MemoryRegion. Board conversion typically involves: * providing MachineClass::default_ram_size and MachineClass::default_ram_id so generic code could create default backend if user didn't explicitly provide memory-backend or -m options * dropping memory_region_allocate_system_memory() call * using convenience MachineState::ram MemoryRegion, which points to MemoryRegion allocated by ram-memdev On top of that for some boards: * missing ram_size checks are added (typically it were boards with fixed ram size) * ram_size fixups are replaced by checks and hard errors, forcing user to provide correct "-m" values instead of ignoring it and continuing running. After all boards are converted, the old API is removed and memory allocation routines are cleaned up.
generated by cgit v1.2.3 (git 2.26.2) at 2025-01-10 14:18:01 +0000