aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2020-06-22Fix tulip breakageHelge Deller1-6/+0
The tulip network driver in a qemu-system-hppa emulation is broken in the sense that bigger network packages aren't received any longer and thus even running e.g. "apt update" inside the VM fails. The breakage was introduced by commit 8ffb7265af ("check frame size and r/w data length") which added checks to prevent accesses outside of the rx/tx buffers. But the new checks were implemented wrong. The variable rx_frame_len counts backwards, from rx_frame_size down to zero, and the variable len is never bigger than rx_frame_len, so accesses just can't happen and the checks are unnecessary. On the contrary the checks now prevented bigger packages to be moved into the rx buffers. This patch reverts the wrong checks and were sucessfully tested with a qemu-system-hppa emulation. Fixes: 8ffb7265af ("check frame size and r/w data length") Buglink: https://bugs.launchpad.net/bugs/1874539 Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit d9b69640391618045949f7c500b87fc129f862ed) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22spapr: Fix failure path for attempting to hot unplug PCI bridgesDavid Gibson1-0/+1
For various technical reasons we can't currently allow unplug a PCI to PCI bridge on the pseries machine. spapr_pci_unplug_request() correctly generates an error message if that's attempted. But.. if the given errp is not error_abort or error_fatal, it doesn't actually stop trying to unplug the bridge anyway. Fixes: 14e714900f6b "spapr: Allow hot plug/unplug of PCI bridges and devices under PCI bridges" Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 7aab5899764887f6b0512cb2e5c11bdc2a5d3644) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22net: tulip: check frame size and r/w data lengthPrasad J Pandit1-9/+27
Tulip network driver while copying tx/rx buffers does not check frame size against r/w data length. This may lead to OOB buffer access. Add check to avoid it. Limit iterations over descriptors to avoid potential infinite loop issue in tulip_xmit_list_update. Reported-by: Li Qiang <pangpei.lq@antfin.com> Reported-by: Ziming Zhang <ezrakiez@gmail.com> Reported-by: Jason Wang <jasowang@redhat.com> Tested-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 8ffb7265af64ec81748335ec8f20e7ab542c3850) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22ppc/ppc405_boards: Remove unnecessary NULL checkPhilippe Mathieu-Daudé1-3/+3
This code is inside the "if (dinfo)" condition, so testing again here whether it is NULL is unnecessary. Fixes: dd59bcae7 (Don't size flash memory to match backing image) Reported-by: Coverity (CID 1421917) Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200320155740.5342-1-philmd@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 1583794b9b36911df116cc726750dadbeeac506a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22hw/arm/cubieboard: use ARM Cortex-A8 as the default CPU in machine definitionNiek Linnenbank1-2/+2
The Cubieboard is a singleboard computer with an Allwinner A10 System-on-Chip [1]. As documented in the Allwinner A10 User Manual V1.5 [2], the SoC has an ARM Cortex-A8 processor. Currently the Cubieboard machine definition specifies the ARM Cortex-A9 in its description and as the default CPU. This patch corrects the Cubieboard machine definition to use the ARM Cortex-A8. The only user-visible effect is that our textual description of the machine was wrong, because hw/arm/allwinner-a10.c always creates a Cortex-A8 CPU regardless of the default value in the MachineClass struct. [1] http://docs.cubieboard.org/products/start#cubieboard1 [2] https://linux-sunxi.org/File:Allwinner_A10_User_manual_V1.5.pdf Fixes: 8a863c8120994981a099 Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20200227220149.6845-2-nieklinnenbank@gmail.com Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [note in commit message that the bug didn't have much visible effect] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 2104df2a1fbf44b2564427aa72fd58d66ce290a7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22vhost-user-blk: delete virtioqueues in unrealize to fix memleaksPan Nengyuan1-0/+8
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> (cherry picked from commit 13e5468127111bf44c5dc314d1dd2ec5a65dfec4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22virtio-crypto: do delete ctrl_vq in virtio_crypto_device_unrealizePan Nengyuan1-1/+2
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> (cherry picked from commit d56e1c8256cb37e68f9b5d98c6cc4e6ca463f1fd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22virtio-pmem: do delete rq_vq in virtio_pmem_unrealizePan Nengyuan1-0/+1
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> (cherry picked from commit 9861546e1dae05c5152de7d3bd14e341ecadc972) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22hw/intc/arm_gicv3_kvm: Stop wrongly programming GICR_PENDBASER.PTZ bitZenghui Yu1-7/+4
If LPIs are disabled, KVM will just ignore the GICR_PENDBASER.PTZ bit when restoring GICR_CTLR. Setting PTZ here makes littlt sense in "reduce GIC initialization time". And what's worse, PTZ is generally programmed by guest to indicate to the Redistributor whether the LPI Pending table is zero when enabling LPIs. If migration is triggered when the PTZ has just been cleared by guest (and before enabling LPIs), we will see PTZ==1 on the destination side, which is not as expected. Let's just drop this hackish userspace behavior. Also take this chance to refine the comment a bit. Fixes: 367b9f527bec ("hw/intc/arm_gicv3_kvm: Implement get/put functions") Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Message-id: 20200119133051.642-1-yuzenghui@huawei.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 618bacabd3c8c3360be795cd8763bacdf5bec101) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22tpm-ppi: page-align PPI RAMMarc-André Lureau1-1/+2
post-copy migration fails on destination with error such as: 2019-12-26T10:22:44.714644Z qemu-kvm: ram_block_discard_range: Unaligned start address: 0x559d2afae9a0 Use qemu_memalign() to constrain the PPI RAM memory alignment. Cc: qemu-stable@nongnu.org Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Message-id: 20200103074000.1006389-3-marcandre.lureau@redhat.com (cherry picked from commit 71e415c8a75c130875f14d6b2136825789feb297) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22s390x: adapter routes error handlingCornelia Huck2-0/+12
If the kernel irqchip has been disabled, we don't want the {add,release}_adapter_routes routines to call any kvm_irqchip_* interfaces, as they may rely on an irqchip actually having been created. Just take a quick exit in that case instead. If you are trying to use irqfd without a kernel irqchip, we will fail with an error. Also initialize routes->gsi[] with -1 in the virtio-ccw handling, to make sure we don't trip over other errors, either. (Nobody else uses the gsi array in that structure.) Fixes: d426d9fba8ea ("s390x/virtio-ccw: wire up irq routing and irqfds") Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20200117111147.5006-1-cohuck@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> (cherry picked from commit 3c5fd8074335c67777d9391b84f97070c35d9c63) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22hw/arm/smmuv3: Report F_STE_FETCH fault address in correct word positionSimon Veith1-1/+1
The smmuv3_record_event() function that generates the F_STE_FETCH error uses the EVT_SET_ADDR macro to record the fetch address, placing it in 32-bit words 4 and 5. The correct position for this address is in words 6 and 7, per the SMMUv3 Architecture Specification. Update the function to use the EVT_SET_ADDR2 macro instead, which is the macro intended for writing to these words. ref. ARM IHI 0070C, section 7.3.4. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-7-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Acked-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit b255cafb59578d16716186ed955717bc8f87bdb7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22hw/arm/smmuv3: Use correct bit positions in EVT_SET_ADDR2 macroSimon Veith1-2/+2
The bit offsets in the EVT_SET_ADDR2 macro do not match those specified in the ARM SMMUv3 Architecture Specification. In all events that use this macro, e.g. F_WALK_EABT, the faulting fetch address or IPA actually occupies the 32-bit words 6 and 7 in the event record contiguously, with the upper and lower unused bits clear due to alignment or maximum supported address bits. How many bits are clear depends on the individual event type. Update the macro to write to the correct words in the event record so that guest drivers can obtain accurate address information on events. ref. ARM IHI 0070C, sections 7.3.12 through 7.3.16. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-6-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Acked-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit a7f65ceb851af5a5b639c6e30801076d848db2c2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22hw/arm/smmuv3: Align stream table base address to table sizeSimon Veith1-4/+14
Per the specification, and as observed in hardware, the SMMUv3 aligns the SMMU_STRTAB_BASE address to the size of the table by masking out the respective least significant bits in the ADDR field. Apply this masking logic to our smmu_find_ste() lookup function per the specification. ref. ARM IHI 0070C, section 6.3.23. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-5-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 41678c33aac61261522b74f08595ccf2221a430a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22hw/arm/smmuv3: Check stream IDs against actual table LOG2SIZESimon Veith1-2/+6
When checking whether a stream ID is in range of the stream table, we have so far been only checking it against our implementation limit (SMMU_IDR1_SIDSIZE). However, the guest can program the STRTAB_BASE_CFG.LOG2SIZE field to a size that is smaller than this limit. Check the stream ID against this limit as well to match the hardware behavior of raising C_BAD_STREAMID events in case the limit is exceeded. Also, ensure that we do not go one entry beyond the end of the table by checking that its index is strictly smaller than the table size. ref. ARM IHI 0070C, section 6.3.24. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-4-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 05ff2fb80ce4ca85d8a39d48ff8156de739b4f51) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22hw/arm/smmuv3: Correct SMMU_BASE_ADDR_MASK valueSimon Veith1-1/+1
There are two issues with the current value of SMMU_BASE_ADDR_MASK: - At the lower end, we are clearing bits [4:0]. Per the SMMUv3 spec, we should also be treating bit 5 as zero in the base address. - At the upper end, we are clearing bits [63:48]. Per the SMMUv3 spec, only bits [63:52] must be explicitly treated as zero. Update the SMMU_BASE_ADDR_MASK value to mask out bits [63:52] and [5:0]. ref. ARM IHI 0070C, section 6.3.23. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-3-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 3293b9f514a413e019b7dbc9d543458075b4849e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22hw/arm/smmuv3: Apply address mask to linear strtab base addressSimon Veith1-1/+1
In the SMMU_STRTAB_BASE register, the stream table base address only occupies bits [51:6]. Other bits, such as RA (bit [62]), must be masked out to obtain the base address. The branch for 2-level stream tables correctly applies this mask by way of SMMU_BASE_ADDR_MASK, but the one for linear stream tables does not. Apply the missing mask in that case as well so that the correct stream base address is used by guests which configure a linear stream table. Linux guests are unaffected by this change because they choose a 2-level stream table layout for the QEMU SMMUv3, based on the size of its stream ID space. ref. ARM IHI 0070C, section 6.3.23. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-2-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Acked-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 3d44c60500785f18bb469c9de0aeba7415c0f28f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22display/bochs-display: fix memory leakCameron Esfahani1-0/+2
Fix memory leak in bochs_display_update(). Leaks 304 bytes per frame. Fixes: 33ebad54056 Signed-off-by: Cameron Esfahani <dirty@apple.com> Message-Id: <d6c26e68db134c7b0c7ce8b61596ca2e65e01e12.1576013209.git.dirty@apple.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 0d82411d0e38a0de7829f97d04406765c8d2210d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22dp8393x: Mask EOL bit from descriptor addresses, take 2Finn Thain1-2/+2
A portion of a recent patch got lost due to a merge snafu. That patch is now commit 88f632fbb1 ("dp8393x: Mask EOL bit from descriptor addresses"). This patch restores the portion that got lost. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <alpine.LNX.2.22.394.2003041421280.12@nippy.intranet> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit a0cf4297d6b8d88047ab00c467f14aecf9c2a8eb) Conflicts: hw/net/dp8393x.c *drop context dep. on 19f70347 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22es1370: check total frame count against current framePrasad J Pandit1-2/+5
A guest user may set channel frame count via es1370_write() such that, in es1370_transfer_audio(), total frame count 'size' is lesser than the number of frames that are processed 'cnt'. int cnt = d->frame_cnt >> 16; int size = d->frame_cnt & 0xffff; if (size < cnt), it results in incorrect calculations leading to OOB access issue(s). Add check to avoid it. Reported-by: Ren Ding <rding@gatech.edu> Reported-by: Hanqing Zhao <hanqing@gatech.edu> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Message-id: 20200514200608.1744203-1-ppandit@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 369ff955a8497988d079c4e3fa1e93c2570c1c69) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22ati-vga: check mm_index before recursive call (CVE-2020-13800)Prasad J Pandit1-2/+8
While accessing VGA registers via ati_mm_read/write routines, a guest may set 's->regs.mm_index' such that it leads to infinite recursion. Check mm_index value to avoid such recursion. Log an error message for wrong values. Reported-by: Ren Ding <rding@gatech.edu> Reported-by: Hanqing Zhao <hanqing@gatech.edu> Reported-by: Yi Ren <c4tren@gmail.com> Message-id: 20200604090830.33885-1-ppandit@redhat.com Suggested-by: BALATON Zoltan <balaton@eik.bme.hu> Suggested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit a98610c429d52db0937c1e48659428929835c455) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22ati-vga: Fix checks in ati_2d_blt() to avoid crashBALATON Zoltan1-11/+26
In some corner cases (that never happen during normal operation but a malicious guest could program wrong values) pixman functions were called with parameters that result in a crash. Fix this and add more checks to disallow such cases. Reported-by: Ziming Zhang <ezrakiez@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20200406204029.19559747D5D@zero.eik.bme.hu Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit ac2071c3791b67fc7af78b8ceb320c01ca1b5df7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-22riscv/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> (cherry picked from commit bb8136df698bd565ee4f6c18d26c50dee320bfe4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-16xen/9pfs: yield when there isn't enough room on the ringStefano Stabellini1-6/+25
Instead of truncating replies, which is problematic, wait until the client reads more data and frees bytes on the reply ring. Do that by calling qemu_coroutine_yield(). The corresponding qemu_coroutine_enter_if_inactive() is called from xen_9pfs_bh upon receiving the next notification from the client. We need to be careful to avoid races in case xen_9pfs_bh and the coroutine are both active at the same time. In xen_9pfs_bh, wait until either the critical section is over (ring->co == NULL) or until the coroutine becomes inactive (qemu_coroutine_yield() was called) before continuing. Then, simply wake up the coroutine if it is inactive. Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <20200521192627.15259-2-sstabellini@kernel.org> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit a4c4d462729466c4756bac8a0a8d77eb63b21ef7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-169pfs: include linux/limits.h for XATTR_SIZE_MAXDan Robertson1-0/+1
linux/limits.h should be included for the XATTR_SIZE_MAX definition used by v9fs_xattrcreate. Fixes: 3b79ef2cf488 ("9pfs: limit xattr size in xattrcreate") Signed-off-by: Dan Robertson <dan@dlrobertson.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <20200515203015.7090-2-dan@dlrobertson.com> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 03556ea920b23c466ce7c1283199033de33ee671) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-169pfs: local: ignore O_NOATIME if we don't have permissionsOmar Sandoval1-0/+13
QEMU's local 9pfs server passes through O_NOATIME from the client. If the QEMU process doesn't have permissions to use O_NOATIME (namely, it does not own the file nor have the CAP_FOWNER capability), the open will fail. This causes issues when from the client's point of view, it believes it has permissions to use O_NOATIME (e.g., a process running as root in the virtual machine). Additionally, overlayfs on Linux opens files on the lower layer using O_NOATIME, so in this case a 9pfs mount can't be used as a lower layer for overlayfs (cf. https://github.com/osandov/drgn/blob/dabfe1971951701da13863dbe6d8a1d172ad9650/vmtest/onoatimehack.c and https://github.com/NixOS/nixpkgs/issues/54509). Luckily, O_NOATIME is effectively a hint, and is often ignored by, e.g., network filesystems. open(2) notes that O_NOATIME "may not be effective on all filesystems. One example is NFS, where the server maintains the access time." This means that we can honor it when possible but fall back to ignoring it. Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Signed-off-by: Omar Sandoval <osandov@fb.com> Message-Id: <e9bee604e8df528584693a4ec474ded6295ce8ad.1587149256.git.osandov@fb.com> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit a5804fcf7b22fc7d1f9ec794dd284c7d504bd16b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-169p/proxy: Fix export_flagsGreg Kurz1-2/+2
The common fsdev options are set by qemu_fsdev_add() before it calls the backend specific option parsing code. In the case of "proxy" this means "writeout" or "readonly" were simply ignored. This has been broken from the beginning. Reported-by: Stéphane Graber <stgraber@ubuntu.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <158349633705.1237488.8895481990204796135.stgit@bahia.lan> (cherry picked from commit 659f1953281bcfa5ac217e42877d7d3c32eeea38) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-16virtio-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> (cherry picked from commit 9580d60e66d1543a0d79265c0085ee09b8782987) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-169p: 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> (cherry picked from commit 846cf408a4c8055063f4a5a71ccf7ed030cdad30) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-169pfs: 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> (cherry picked from commit 841b8d099c462cd4282c4ced8c2a6512899fd8d9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-15virtio-balloon: unref the iothread when unrealizingDavid Hildenbrand1-0/+1
We took a reference when realizing, so let's drop that reference when unrealizing. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Fixes: c13c4153f76d ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT") Cc: qemu-stable@nongnu.org Cc: Wei Wang <wei.w.wang@intel.com> Cc: Alexander Duyck <alexander.duyck@gmail.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200520100439.19872-4-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 105aef9c9479786d27c1c45c9b0b1fa03dc46be3) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-15virtio-balloon: fix free page hinting check on unrealizeDavid Hildenbrand1-1/+1
Checking against guest features is wrong. We allocated data structures based on host features. We can rely on "free_page_bh" as an indicator whether to un-do stuff instead. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Fixes: c13c4153f76d ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT") Cc: qemu-stable@nongnu.org Cc: Wei Wang <wei.w.wang@intel.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200520100439.19872-3-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 49b01711b8eb3796c6904c7f85d2431572cfe54f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-15virtio-balloon: fix free page hinting without an iothreadDavid Hildenbrand1-17/+16
In case we don't have an iothread, we mark the feature as abscent but still add the queue. 'free_page_bh' remains set to NULL. qemu-system-i386 \ -M microvm \ -nographic \ -device virtio-balloon-device,free-page-hint=true \ -nographic \ -display none \ -monitor none \ -serial none \ -qtest stdio Doing a "write 0xc0000e30 0x24 0x030000000300000003000000030000000300000003000000030000000300000003000000" We will trigger a SEGFAULT. Let's move the check and bail out. While at it, move the static initializations to instance_init(). free_page_report_status and block_iothread are implicitly set to the right values (0/false) already, so drop the initialization. Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Fixes: c13c4153f76d ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT") Reported-by: Alexander Bulekov <alxndr@bu.edu> Cc: qemu-stable@nongnu.org Cc: Wei Wang <wei.w.wang@intel.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200520100439.19872-2-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 12fc8903a8ee09fb5f642de82699a0b211e1b5a7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-099p: Lock directory streams with a CoMutexGreg Kurz1-4/+4
Locking was introduced in QEMU 2.7 to address the deprecation of readdir_r(3) in glibc 2.24. It turns out that the frontend code is the worst place to handle a critical section with a pthread mutex: the code runs in a coroutine on behalf of the QEMU mainloop and then yields control, waiting for the fsdev backend to process the request in a worker thread. If the client resends another readdir request for the same fid before the previous one finally unlocked the mutex, we're deadlocked. This never bit us because the linux client serializes readdir requests for the same fid, but it is quite easy to demonstrate with a custom client. A good solution could be to narrow the critical section in the worker thread code and to return a copy of the dirent to the frontend, but this causes quite some changes in both 9p.c and codir.c. So, instead of that, in order for people to easily backport the fix to older QEMU versions, let's simply use a CoMutex since all the users for this sit in coroutines. Fixes: 7cde47d4a89d ("9p: add locking to V9fsDir") Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <158981894794.109297.3530035833368944254.stgit@bahia.lan> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit ed463454efd0ac3042ff772bfe1b1d846dc281a5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-09xen-block: Fix double qlist remove and request leakAnthony PERARD1-32/+16
Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on remove") revealed that a request was removed twice from a list, once in xen_block_finish_request() and a second time in xen_block_release_request() when both function are called from xen_block_complete_aio(). But also, the `requests_inflight' counter is decreased twice, and thus became negative. This is a bug that was introduced in bfd0d6366043 ("xen-block: improve response latency"), where a `finished' list was removed. That commit also introduced a leak of request in xen_block_do_aio(). That function calls xen_block_finish_request() but the request is never released after that. To fix both issue, we do two changes: - we squash finish_request() and release_request() together as we want to remove a request from 'inflight' list to add it to 'freelist'. - before releasing a request, we need to let the other end know the result, thus we should call xen_block_send_response() before releasing a request. The first change fixes the double QLIST_REMOVE() as we remove the extra call. The second change makes the leak go away because if we want to call finish_request(), we need to call a function that does all of finish, send response, and release. Fixes: bfd0d6366043 ("xen-block: improve response latency") Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200406140217.1441858-1-anthony.perard@citrix.com> Reviewed-by: Paul Durrant <paul@xen.org> [mreitz: Amended commit message as per Paul's suggestions] Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 36d883ba0de8a281072ded2b51e0a711fd002139) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-09hw/i386/amd_iommu.c: Fix corruption of log events passed to guestPeter Maydell1-1/+1
In the function amdvi_log_event(), we write an event log buffer entry into guest ram, whose contents are passed to the function via the "uint64_t *evt" argument. Unfortunately, a spurious '&' in the call to dma_memory_write() meant that instead of writing the event to the guest we would write the literal value of the pointer, plus whatever was in the following 8 bytes on the stack. This error was spotted by Coverity. Fix the bug by removing the '&'. Fixes: CID 1421945 Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200326105349.24588-1-peter.maydell@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 32a2d6b1f6b4405f0fc20c031e61d5d48e3d9cd1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-03compat: disable edid on correct virtio-gpu deviceCornelia Huck1-1/+1
Commit bb15791166c1 ("compat: disable edid on virtio-gpu base device") tried to disable 'edid' on the virtio-gpu base device. However, that device is not 'virtio-gpu', but 'virtio-gpu-device'. Fix it. Fixes: bb15791166c1 ("compat: disable edid on virtio-gpu base device") Reported-by: Lukáš Doktor <ldoktor@redhat.com> Tested-by: Lukáš Doktor <ldoktor@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-id: 20200318093919.24942-1-cohuck@redhat.com Cc: qemu-stable@nongnu.org Signed-off-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 02501fc39381c4dabaf6becdd12c2a4754c3847c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-03virtio: gracefully handle invalid region cachesStefan Hajnoczi1-8/+91
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> (cherry picked from commit abdd16f4681cc4d6bf84990227b5c9b98e869ccd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-02dp8393x: Don't stop reception upon RBE interrupt assertionFinn Thain1-13/+22
Section 3.4.7 of the datasheet explains that, The RBE bit in the Interrupt Status register is set when the SONIC finishes using the second to last receive buffer and reads the last RRA descriptor. Actually, the SONIC is not truly out of resources, but gives the system an early warning of an impending out of resources condition. RBE does not mean actual receive buffer exhaustion, and reception should not be stopped. This is important because Linux will not check and clear the RBE interrupt until it receives another packet. But that won't happen if can_receive returns false. This bug causes the SONIC to become deaf (until reset). Fix this with a new flag to indicate actual receive buffer exhaustion. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit c2279bd0a19b35057f2e4c3b4df9a915717d1142) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-02dp8393x: Don't reset Silicon Revision registerFinn Thain1-1/+1
The jazzsonic driver in Linux uses the Silicon Revision register value to probe the chip. The driver fails unless the SR register contains 4. Unfortunately, reading this register in QEMU usually returns 0 because the s->regs[] array gets wiped after a software reset. Fixes: bd8f1ebce4 ("net/dp8393x: fix hardware reset") Suggested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 083e21bbdde7dbd326baf29d21f49fc3f5614496) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-02dp8393x: Always update RRA pointers and sequence numbersFinn Thain1-5/+7
These operations need to take place regardless of whether or not rx descriptors have been used up (that is, EOL flag was observed). The algorithm is now the same for a packet that was withheld as for a packet that was not. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 80b60673ea598869050c66d95d8339480e4cefd0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-02dp8393x: Clear descriptor in_use field to release packetFinn Thain1-0/+10
When the SONIC receives a packet into the last available descriptor, it retains ownership of that descriptor for as long as necessary. Section 3.4.7 of the datasheet says, When the system appends more descriptors, the SONIC releases ownership of the descriptor after writing 0000h to the RXpkt.in_use field. The packet can now be processed by the host, so raise a PKTRX interrupt, just like the normal case. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit d9fae13196a31716f45dcddcdd958fbb8e59b35a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-02dp8393x: Pad frames to word or long word boundaryFinn Thain1-11/+28
The existing code has a bug where the Remaining Buffer Word Count (RBWC) is calculated with a truncating division, which gives the wrong result for odd-sized packets. Section 1.4.1 of the datasheet says, Once the end of the packet has been reached, the serializer will fill out the last word (16-bit mode) or long word (32-bit mode) if the last byte did not end on a word or long word boundary respectively. The fill byte will be 0FFh. Implement buffer padding so that buffer limits are correctly enforced. 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> (cherry picked from commit 350e7d9a77d3b9ac74d240e4b232db1ebe5c05bc) *drop context dependencies from b7cbebf2b9d, 1ccda935d4f, and 19f70347731 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-02dp8393x: Use long-word-aligned RRA pointers in 32-bit modeFinn Thain1-2/+6
Section 3.4.1 of the datasheet says, The alignment of the RRA is confined to either word or long word boundaries, depending upon the data width mode. In 16-bit mode, the RRA must be aligned to a word boundary (A0 is always zero) and in 32-bit mode, the RRA is aligned to a long word boundary (A0 and A1 are always zero). This constraint has been implemented for 16-bit mode; implement it for 32-bit mode too. 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> (cherry picked from commit ea2270279bc2e1635cb6e909e22e17e630198773) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-02dp8393x: Don't clobber packet checksumFinn Thain1-0/+1
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> (cherry picked from commit bae112b80c9c42cea21ee7623c283668c3451c2e) *drop context dep. on 19f70347731 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-02dp8393x: Implement packet size limit and RBAE interruptFinn Thain1-0/+9
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> (cherry picked from commit ada74315270d1dcabf4c9d4fece19df7ef5b9577) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-02dp8393x: Clear RRRA command register bit only when appropriateFinn Thain1-4/+3
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> (cherry picked from commit a3cce2825a0b12bb717a5106daaca245557cc9ae) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-02dp8393x: Update LLFA and CRDA registers from rx descriptorFinn Thain1-4/+7
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> (cherry picked from commit 5b0c98fcb7ac006bd8efe0e0fecba52c43a9d028) *drop context dep on 19f70347731 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-02dp8393x: Have dp8393x_receive() return the packet sizeFinn Thain1-4/+5
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> (cherry picked from commit 9e3cd456d85ad45e72bdba99203302342ce29b3b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-06-02dp8393x: Clean up endianness hacksFinn Thain1-11/+6
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> (cherry picked from commit 46ffee9ad43185cbee4182c208bbd534814086ca) Conflicts: hw/net/dp8393x.c *roll in local dependencies on b7cbebf2b9d *drop functional dep. on 19f70347731 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
generated by cgit v1.1 at 2025-09-18 07:12:09 +0000