aboutsummaryrefslogtreecommitdiff
path: root/hw/net
AgeCommit message (Collapse)Author
2022-01-20hw/net: Move MV88W8618 network device out of hw/arm/ directoryPhilippe Mathieu-Daudé
The Marvell 88W8618 network device is hidden in the Musicpal machine. Move it into a new unit file under the hw/net/ directory. Acked-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20220107184429.423572-4-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-10Revert "virtio: introduce macro IRTIO_CONFIG_IRQ_IDX"Michael S. Tsirkin
This reverts commit bf1d85c166c19af95dbd27b1faba1d2909732323. Fixes: bf1d85c166 ("virtio: introduce macro IRTIO_CONFIG_IRQ_IDX") Cc: "Cindy Lu" <lulu@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-10Revert "virtio-net: add support for configure interrupt"Michael S. Tsirkin
This reverts commit 497679d51087090d5a22fd265d1b96cf92d49d9d. Fixes: 497679d510 ("virtio-net: add support for configure interrupt") Cc: "Cindy Lu" <lulu@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-07virtio-net: add support for configure interruptCindy Lu
Add functions to support configure interrupt in virtio_net The functions are config_pending and config_mask, while this input idx is VIRTIO_CONFIG_IRQ_IDX will check the function of configure interrupt. Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20211104164827.21911-9-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-06virtio: introduce macro IRTIO_CONFIG_IRQ_IDXCindy Lu
To support configure interrupt for vhost-vdpa Introduce VIRTIO_CONFIG_IRQ_IDX -1 as configure interrupt's queue index, Then we can reuse the functions guest_notifier_mask and guest_notifier_pending. Add the check of queue index in these drivers, if the driver does not support configure interrupt, the function will just return Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20211104164827.21911-2-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-31pci: Let ld*_pci_dma() propagate MemTxResultPhilippe Mathieu-Daudé
ld*_dma() returns a MemTxResult type. Do not discard it, return it to the caller. Update the few callers. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211223115554.3155328-24-philmd@redhat.com>
2021-12-31pci: Let ld*_pci_dma() take MemTxAttrs argumentPhilippe Mathieu-Daudé
Let devices specify transaction attributes when calling ld*_pci_dma(). Keep the default MEMTXATTRS_UNSPECIFIED in the few callers. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211223115554.3155328-22-philmd@redhat.com>
2021-12-31pci: Let st*_pci_dma() take MemTxAttrs argumentPhilippe Mathieu-Daudé
Let devices specify transaction attributes when calling st*_pci_dma(). Keep the default MEMTXATTRS_UNSPECIFIED in the few callers. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211223115554.3155328-21-philmd@redhat.com>
2021-12-30dma: Let dma_memory_read/write() take MemTxAttrs argumentPhilippe Mathieu-Daudé
Let devices specify transaction attributes when calling dma_memory_read() or dma_memory_write(). Patch created mechanically using spatch with this script: @@ expression E1, E2, E3, E4; @@ ( - dma_memory_read(E1, E2, E3, E4) + dma_memory_read(E1, E2, E3, E4, MEMTXATTRS_UNSPECIFIED) | - dma_memory_write(E1, E2, E3, E4) + dma_memory_write(E1, E2, E3, E4, MEMTXATTRS_UNSPECIFIED) ) Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20211223115554.3155328-6-philmd@redhat.com>
2021-12-22failover: Silence warning messages during qtestLaurent Vivier
virtio-net-failover test tries several device combinations that produces some expected warnings. These warning can be confusing, so we disable them during the qtest sequence. Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20211220145314.390697-1-lvivier@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> [thuth: Fix memory leak by using error_free()] Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-12-15hw/net: npcm7xx_emc fix missing queue_flushPatrick Venture
The rx_active boolean change to true should always trigger a try_read call that flushes the queue. Signed-off-by: Patrick Venture <venture@google.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20211203221002.1719306-1-venture@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-11-19net: vmxnet3: validate configuration values during activate (CVE-2021-20203)Prasad J Pandit
While activating device in vmxnet3_acticate_device(), it does not validate guest supplied configuration values against predefined minimum - maximum limits. This may lead to integer overflow or OOB access issues. Add checks to avoid it. Fixes: CVE-2021-20203 Buglink: https://bugs.launchpad.net/qemu/+bug/1913873 Reported-by: Gaoning Pan <pgn@zju.edu.cn> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Jason Wang <jasowang@redhat.com>
2021-11-11vhost: Fix last vq queue index of devices with no cvqEugenio Pérez
The -1 assumes that cvq device model is accounted in data_queue_pairs, if cvq does not exists, but it's actually the opposite: Devices with !cvq are ok but devices with cvq does not add the last queue to data_queue_pairs. This is not a problem to vhost-net, but it is to vhost-vdpa: * Devices with cvq gets initialized at last data vq device model, not at cvq one. * Devices with !cvq never gets initialized, since last_index is the first queue of the last device model. Because of that, the right change in last_index is to actually add the cvq, not to remove the missing one. This is not a problem to vhost-net, but it is to vhost-vdpa, which device model trust to reach the last index to finish starting the device. Also, as the previous commit, rename it to index_end. Tested with vp_vdpa with host's vhost=on and vhost=off, with ctrl_vq=on and ctrl_vq=off. Fixes: 049eb15b5fc9 ("vhost: record the last virtqueue index for the virtio device") Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20211104085625.2054959-3-eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-11vhost: Rename last_index to vq_index_endEugenio Pérez
The doc of this field pointed out that last_index is the last vq index. This is misleading, since it's actually one past the end of the vqs. Renaming and modifying comment. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20211104085625.2054959-2-eperezma@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-05e1000: fix tx re-entrancy problemJon Maloy
The fact that the MMIO handler is not re-entrant causes an infinite loop under certain conditions: Guest write to TDT -> Loopback -> RX (DMA to TDT) -> TX We now eliminate the effect of this problem locally in e1000, by adding a boolean in struct E1000State indicating when the TX side is busy. This will cause any entering new call to return early instead of interfering with the ongoing work, and eliminates any risk of looping. This is intended to address CVE-2021-20257. Signed-off-by: Jon Maloy <jmaloy@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2021-10-20virtio-net: vhost control virtqueue supportJason Wang
This patch implements the control virtqueue support for vhost. This requires virtio-net to figure out the datapath queue pairs and control virtqueue via is_datapath and pass the number of those two types of virtqueues to vhost_net_start()/vhost_net_stop(). Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20211020045600.16082-10-jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-20vhost: record the last virtqueue index for the virtio deviceJason Wang
This patch introduces a new field in the vhost_dev structure to record the last virtqueue index for the virtio device. This will be useful for the vhost backends with 1:N model to start or stop the device after all the vhost_dev structures were started or stopped. Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20211020045600.16082-9-jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-20virtio-net: use "queue_pairs" instead of "queues" when possibleJason Wang
Most of the time, "queues" really means queue pairs. So this patch switch to use "queue_pairs" to avoid confusion. Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20211020045600.16082-8-jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-20vhost-net: control virtqueue supportJason Wang
We assume there's no cvq in the past, this is not true when we need control virtqueue support for vhost-user backends. So this patch implements the control virtqueue support for vhost-net. As datapath, the control virtqueue is also required to be coupled with the NetClientState. The vhost_net_start/stop() are tweaked to accept the number of datapath queue pairs plus the the number of control virtqueue for us to start and stop the vhost device. Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20211020045600.16082-7-jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-20qdev/qbus: remove failover specific codeLaurent Vivier
Commit f3a850565693 ("qdev/qbus: add hidden device support") has introduced a generic way to hide a device but it has modified qdev_device_add() to check a specific option of the failover device, "failover_pair_id", before calling the generic mechanism. It's not needed (and not generic) to do that in qdev_device_add() because this is also checked by the failover_hide_primary_device() function that uses the generic mechanism to hide the device. Cc: Jens Freimann <jfreimann@redhat.com> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20211019071532.682717-3-lvivier@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2021-10-20failover: fix a regression introduced by JSON'ification of -deviceLaurent Vivier
The hide_device helper can be called several times for the same devices as it shouldn't change any state and should only return an information. But not to rely anymore on QemuOpts we have introduced a new field to store the parameters of the device and don't allow to update it once it is done. And as the function is called several times, we ends with: warning: Cannot attach more than one primary device to 'virtio0' That is not only a warning as it prevents to hide the device and breaks failover. Fix that by checking the device id. Now, we fail only if the virtio-net device is really used by two different devices, for instance: -device virtio-net-pci,id=virtio0,failover=on,... \ -device vfio-pci,id=hostdev0,failover_pair_id=virtio0,... \ -device e1000e,id=e1000e0,failover_pair_id=virtio0,... \ will exit with: Cannot attach more than one primary device to 'virtio0': 'hostdev0' and 'e1000e0' Fixes: 259a10dbcb4f ("virtio-net: Store failover primary opts pointer locally") Cc: kwolf@redhat.com Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20211019071532.682717-2-lvivier@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2021-10-15qdev: Base object creation on QDict rather than QemuOptsKevin Wolf
QDicts are both what QMP natively uses and what the keyval parser produces. Going through QemuOpts isn't useful for either one, so switch the main device creation function to QDicts. By sharing more code with the -object/object-add code path, we can even reduce the code size a bit. This commit doesn't remove the detour through QemuOpts from any code path yet, but it allows the following commits to do so. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20211008133442.141332-15-kwolf@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-10-15virtio-net: Avoid QemuOpts in failover_find_primary_device()Kevin Wolf
Don't go through the global QemuOptsList, it is state of the legacy command line parser and we will create devices that are not contained in it. It is also just the command line configuration and not necessarily the current runtime state. Instead, look at the qdev device tree which has the current state of all existing devices. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20211008133442.141332-14-kwolf@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-10-15virtio-net: Store failover primary opts pointer locallyKevin Wolf
Instead of accessing the global QemuOptsList, which really belong to the command line parser and shouldn't be accessed from devices, store a pointer to the QemuOpts in a new VirtIONet field. This is not the final state, but just an intermediate step to get rid of QemuOpts in devices. It will later be replaced with an options QDict. Before this patch, two "primary" devices could be hidden for the same standby device, but only one of them would actually be enabled and the other one would be kept hidden forever, so this doesn't make sense. After this patch, configuring a second primary device is an error. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20211008133442.141332-13-kwolf@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-10-15qdev: Add Error parameter to hide_device() callbacksKevin Wolf
hide_device() is used for virtio-net failover, where the standby virtio device delays creation of the primary device. It only makes sense to have a single primary device for each standby device. Adding a second one should result in an error instead of hiding it and never using it afterwards. Prepare for this by adding an Error parameter to the hide_device() callback where virtio-net is informed about adding a primary device. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20211008133442.141332-12-kwolf@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-09-17virtio-net: fix use after unmap/free for sgJason Wang
When mergeable buffer is enabled, we try to set the num_buffers after the virtqueue elem has been unmapped. This will lead several issues, E.g a use after free when the descriptor has an address which belongs to the non direct access region. In this case we use bounce buffer that is allocated during address_space_map() and freed during address_space_unmap(). Fixing this by storing the elems temporarily in an array and delay the unmap after we set the the num_buffers. This addresses CVE-2021-3748. Reported-by: Alexander Bulekov <alxndr@bu.edu> Fixes: fbe78f4f55c6 ("virtio-net support") Cc: qemu-stable@nongnu.org Signed-off-by: Jason Wang <jasowang@redhat.com>
2021-09-04vhost_net: do not assume nvqs is always 2Jason Wang
This patch switches to initialize dev.nvqs from the VhostNetOptions instead of assuming it was 2. This is useful for implementing control virtqueue support which will be a single vhost_net structure with a single cvq. Note that nvqs is still set to 2 for all users and this patch does not change functionality. Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Eli Cohen <elic@nvidia.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20210903091031.47303-6-jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-09-04vhost_net: remove the meaningless assignment in vhost_net_start_one()Jason Wang
The nvqs and vqs have been initialized during vhost_net_init() and are not expected to change during the life cycle of vhost_net structure. So this patch removes the meaningless assignment. Reviewed-by: Eli Cohen <elic@nvidia.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20210903091031.47303-4-jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-08-02hw/net: e1000e: Don't zero out the VLAN tag in the legacy RX descriptorChristina Wang
In the legacy RX descriptor mode, VLAN tag was saved to d->special by e1000e_build_rx_metadata() in e1000e_write_lgcy_rx_descr(), but it was then zeroed out again at the end of the call, which is wrong. Fixes: c89d416a2b0f ("e1000e: Don't zero out buffer address in rx descriptor") Reported-by: Markus Carlstedt <markus.carlstedt@windriver.com> Signed-off-by: Christina Wang <christina.wang@windriver.com> Signed-off-by: Bin Meng <bin.meng@windriver.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2021-08-02hw/net: e1000e: Correct the initial value of VET registerChristina Wang
The initial value of VLAN Ether Type (VET) register is 0x8100, as per the manual and real hardware. While Linux e1000e driver always writes VET register to 0x8100, it is not always the case for everyone. Drivers relying on the reset value of VET won't be able to transmit and receive VLAN frames in QEMU. Unlike e1000 in QEMU, e1000e uses a field 'vet' in "struct E1000Core" to cache the value of VET register, but the cache only gets updated when VET register is written. To always get a consistent VET value no matter VET is written or remains its reset value, drop the 'vet' field and use 'core->mac[VET]' directly. Reported-by: Markus Carlstedt <markus.carlstedt@windriver.com> Signed-off-by: Christina Wang <christina.wang@windriver.com> Signed-off-by: Bin Meng <bin.meng@windriver.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2021-08-02hw/net: e1000: Correct the initial value of VET registerChristina Wang
The initial value of VLAN Ether Type (VET) register is 0x8100, as per the manual and real hardware. While Linux e1000 driver always writes VET register to 0x8100, it is not always the case for everyone. Drivers relying on the reset value of VET won't be able to transmit and receive VLAN frames in QEMU. Reported-by: Markus Carlstedt <markus.carlstedt@windriver.com> Signed-off-by: Christina Wang <christina.wang@windriver.com> Signed-off-by: Bin Meng <bin.meng@windriver.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2021-08-02hw/net/can: sja1000 fix buff2frame_bas and buff2frame_pel when dlc is out of ↵Pavel Pisa
std CAN 8 bytes Problem reported by openEuler fuzz-sig group. The buff2frame_bas function (hw\net\can\can_sja1000.c) infoleak(qemu5.x~qemu6.x) or stack-overflow(qemu 4.x). Reported-by: Qiang Ning <ningqiang1@huawei.com> Cc: qemu-stable@nongnu.org Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Signed-off-by: Jason Wang <jasowang@redhat.com>
2021-08-02hw/net/vmxnet3: Do not abort QEMU if guest specified bad queue numbersThomas Huth
QEMU should never terminate unexpectedly just because the guest is doing something wrong like specifying wrong queue numbers. Let's simply refuse to set the device active in this case. Buglink: https://bugs.launchpad.net/qemu/+bug/1890160 Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2021-07-19hw/net/net_tx_pkt: Fix crash detected by fuzzerThomas Huth
QEMU currently crashes when it's started like this: cat << EOF | ./qemu-system-i386 -device vmxnet3 -nodefaults -qtest stdio outl 0xcf8 0x80001014 outl 0xcfc 0xe0001000 outl 0xcf8 0x80001018 outl 0xcf8 0x80001004 outw 0xcfc 0x7 outl 0xcf8 0x80001083 write 0x0 0x1 0xe1 write 0x1 0x1 0xfe write 0x2 0x1 0xbe write 0x3 0x1 0xba writeq 0xe0001020 0xefefff5ecafe0000 writeq 0xe0001020 0xffff5e5ccafe0002 EOF It hits this assertion: qemu-system-i386: ../qemu/hw/net/net_tx_pkt.c:453: net_tx_pkt_reset: Assertion `pkt->raw' failed. This happens because net_tx_pkt_init() is called with max_frags == 0 and thus the allocation p->raw = g_new(struct iovec, max_frags); results in a NULL pointer that causes the assert(pkt->raw); in net_tx_pkt_reset() to fail later. To fix this issue we can check that max_raw_frags was not zero before asserting that pkt->raw is a non-NULL pointer. Buglink: https://bugs.launchpad.net/qemu/+bug/1890157 Message-Id: <20210715193219.1132571-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-07-19hw/net/vmxnet3: Do not abort if the guest is trying to use an invalid TX queueThomas Huth
QEMU should never abort just because the guest is doing something odd. Let's simply log the error and ignore the bad transmit queue instead. Buglink: https://bugs.launchpad.net/qemu/+bug/1926111 Message-Id: <20210715103755.1035566-1-thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-07-14net/rocker: use GDateTime for formatting timestamp in debug messagesDaniel P. Berrangé
The GDateTime APIs provided by GLib avoid portability pitfalls, such as some platforms where 'struct timeval.tv_sec' field is still 'long' instead of 'time_t'. When combined with automatic cleanup, GDateTime often results in simpler code too. Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-07-11dp8393x: don't force 32-bit register accessMark Cave-Ayland
Commit 3fe9a838ec "dp8393x: Always use 32-bit accesses" set .impl.min_access_size and .impl.max_access_size to 4 to try and fix the Linux jazzsonic driver which uses 32-bit accesses. The problem with forcing the register access to 32-bit in this way is that since the dp8393x uses 16-bit registers, a manual endian swap is required for devices on big endian machines with 32-bit accesses. For both access sizes and machine endians the QEMU memory API can do the right thing automatically: all that is needed is to set .impl.min_access_size to 2 to declare that the dp8393x implements 16-bit registers. Normally .impl.max_access_size should also be set to 2, however that doesn't quite work in this case since the register stride is specified using a (dynamic) it_shift property which is applied during the MMIO access itself. The effect of this is that for a 32-bit access the memory API performs 2 x 16-bit accesses, but the use of it_shift within the MMIO access itself causes the register value to be repeated in both the top 16-bits and bottom 16-bits. The Linux jazzsonic driver expects the stride to be zero-extended up to access size and therefore fails to correctly detect the dp8393x device due to the extra data in the top 16-bits. The solution here is to remove .impl.max_access_size so that the memory API will correctly zero-extend the 16-bit registers to the access size up to and including it_shift. Since it_shift is never greater than 2 than this will always do the right thing for both 16-bit and 32-bit accesses regardless of the machine endian, allowing the manual endian swap code to be removed. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Fixes: 3fe9a838ec ("dp8393x: Always use 32-bit accesses") Message-Id: <20210705214929.17222-2-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Finn Thain <fthain@linux-m68k.org> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-07-11dp8393x: Rewrite dp8393x_get() / dp8393x_put()Philippe Mathieu-Daudé
Instead of accessing N registers via a single address_space API call using a temporary buffer (stored in the device state) and updating each register, move the address_space call in the register put/get. The load/store and word size checks are moved to put/get too. This simplifies a bit, making the code easier to read. Co-developed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Co-developed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Finn Thain <fthain@linux-m68k.org> Message-Id: <20210710174954.2577195-8-f4bug@amsat.org>
2021-07-11dp8393x: Store CAM registers as 16-bitPhilippe Mathieu-Daudé
Per the DP83932C datasheet from July 1995: 4.0 SONIC Registers 4.1 THE CAM UNIT The Content Addressable Memory (CAM) consists of sixteen 48-bit entries for complete address filtering of network packets. Each entry corresponds to a 48-bit destination address that is user programmable and can contain any combination of Multicast or Physical addresses. Each entry is partitioned into three 16-bit CAM cells accessible through CAM Address Ports (CAP 2, CAP 1 and CAP 0) with CAP0 corresponding to the least significant 16 bits of the Destination Address and CAP2 corresponding to the most significant bits. Store the CAM registers as 16-bit as it simplifies the code. Having now the CAM registers as arrays of 3 uint16_t, we can avoid using the VMSTATE_BUFFER_UNSAFE macro by using VMSTATE_UINT16_2DARRAY which is more appropriate. This breaks the migration stream however. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Finn Thain <fthain@linux-m68k.org> Message-Id: <20210710174954.2577195-5-f4bug@amsat.org> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-07-11dp8393x: Replace 0x40 magic value by SONIC_REG_COUNT definitionPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Finn Thain <fthain@linux-m68k.org> Message-Id: <20210710174954.2577195-3-f4bug@amsat.org> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-07-11dp8393x: Replace address_space_rw(is_write=1) by address_space_write()Philippe Mathieu-Daudé
Replace address_space_rw(is_write=1) by address_space_write() and remove pointless cast. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Finn Thain <fthain@linux-m68k.org> Message-Id: <20210710174954.2577195-2-f4bug@amsat.org> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-07-11dp8393x: fix CAM descriptor entry indexMark Cave-Ayland
Currently when a LOAD CAM command is executed the entries are loaded into the CAM from memory in order which is incorrect. According to the datasheet the first entry in the CAM descriptor is the entry index which means that each descriptor may update any single entry in the CAM rather than the Nth entry. Decode the CAM entry index and use it store the descriptor in the appropriate slot in the CAM. This fixes the issue where the MacOS toolbox loads a single CAM descriptor into the final slot in order to perform a loopback test which must succeed before the Ethernet port is enabled. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Finn Thain <fthain@linux-m68k.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210625065401.30170-10-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-07-09Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell
pc,pci,virtio: bugfixes, improvements vhost-user-rng support. Fixes all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Wed 07 Jul 2021 14:29:30 BST # 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: MAINTAINERS: Add maintainer for vhost-user RNG implementation docs: add slot when adding new PCIe root port acpi/ged: fix reset cause tests: acpi: pc: update expected DSDT blobs acpi: pc: revert back to v5.2 PCI slot enumeration tests: acpi: prepare for changing DSDT tables migration: failover: reset partially_hotplugged virtio-pci: Changed return values for "notify", "device" and "isr" read. virtio-pci: Added check for virtio device in PCI config cbs. virtio-pci: Added check for virtio device presence in mm callbacks. hw/pci-host/q35: Ignore write of reserved PCIEXBAR LENGTH field virtio: Clarify MR transaction optimization virtio: disable ioeventfd for record/replay Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-04Merge remote-tracking branch 'remotes/philmd/tags/mips-20210702' into stagingPeter Maydell
MIPS patches queue - Extract nanoMIPS, microMIPS, Code Compaction from translate.c - Allow PCI config accesses smaller than 32-bit on Bonito64 device - Fix migration of g364fb device on Jazz Magnum - Fix dp8393x PROM checksum on Jazz Magnum and Quadra 800 - Map the UART devices unconditionally on Jazz Magnum - Add functional test booting Linux on the Fuloong 2E # gpg: Signature made Fri 02 Jul 2021 16:36:19 BST # gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full] # Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE * remotes/philmd/tags/mips-20210702: hw/mips/jazz: Map the UART devices unconditionally hw/mips/jazz: specify correct endian for dp8393x device hw/m68k/q800: fix PROM checksum and MAC address storage qemu/bitops.h: add bitrev8 implementation dp8393x: remove onboard PROM containing MAC address and checksum hw/m68k/q800: move PROM and checksum calculation from dp8393x device to board hw/mips/jazz: move PROM and checksum calculation from dp8393x device to board dp8393x: convert to trace-events dp8393x: checkpatch fixes g364fb: add VMStateDescription for G364SysBusState g364fb: use RAM memory region for framebuffer tests/acceptance: Test Linux on the Fuloong 2E machine hw/pci-host/bonito: Allow PCI config accesses smaller than 32-bit hw/pci-host/bonito: Trace PCI config accesses smaller than 32-bit target/mips: Extract nanoMIPS ISA translation routines target/mips: Extract the microMIPS ISA translation routines target/mips: Extract Code Compaction ASE translation routines target/mips: Add declarations for generic TCG helpers Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-03migration: failover: reset partially_hotpluggedLaurent Vivier
When the card is plugged back, reset the partially_hotplugged flag to false Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1787194 Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20210629152937.619193-1-lvivier@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-07-02dp8393x: remove onboard PROM containing MAC address and checksumMark Cave-Ayland
According to the datasheet the dp8393x chipset does not contain any NVRAM capable of storing a MAC address or checksum. Now that both the MIPS jazz and m68k q800 boards generate the PROM region and checksum themselves, remove the generated PROM from the dp8393x device itself. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Finn Thain <fthain@linux-m68k.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210625065401.30170-6-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-07-02dp8393x: convert to trace-eventsMark Cave-Ayland
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Finn Thain <fthain@linux-m68k.org> Message-Id: <20210625065401.30170-3-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-07-02dp8393x: checkpatch fixesMark Cave-Ayland
Also fix a simple comment typo of "constrainst" to "constraints". Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Finn Thain <fthain@linux-m68k.org> Message-Id: <20210625065401.30170-2-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-06-30vhost: Distinguish errors in vhost_dev_get_config()Kevin Wolf
Instead of just returning 0/-1 and letting the caller make up a meaningless error message, add an Error parameter to allow reporting the real error and switch to 0/-errno so that different kind of errors can be distinguished in the caller. config_len in vhost_user_get_config() is defined by the device, so if it's larger than VHOST_USER_MAX_CONFIG_SIZE, this is a programming error. Turn the corresponding check into an assertion. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20210609154658.350308-6-kwolf@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-06-30vhost: Add Error parameter to vhost_dev_init()Kevin Wolf
This allows callers to return better error messages instead of making one up while the real error ends up on stderr. Most callers can immediately make use of this because they already have an Error parameter themselves. The others just keep printing the error with error_report_err(). Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20210609154658.350308-2-kwolf@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>