aboutsummaryrefslogtreecommitdiff
path: root/hw/net
AgeCommit message (Collapse)Author
2024-06-11virtio-net: drop too short packets earlyAlexey Dobriyan
Reproducer from https://gitlab.com/qemu-project/qemu/-/issues/1451 creates small packet (1 segment, len = 10 == n->guest_hdr_len), then destroys queue. "if (n->host_hdr_len != n->guest_hdr_len)" is triggered, if body creates zero length/zero segment packet as there is nothing after guest header. qemu_sendv_packet_async() tries to send it. slirp discards it because it is smaller than Ethernet header, but returns 0 because tx hooks are supposed to return total length of data. 0 is propagated upwards and is interpreted as "packet has been sent" which is terrible because queue is being destroyed, nobody is waiting for TX to complete and assert it triggered. Fix is discard such empty packets instead of sending them. Length 1 packets will go via different codepath: virtqueue_push(q->tx_vq, elem, 0); virtio_notify(vdev, q->tx_vq); g_free(elem); and aren't problematic. Signed-off-by: Alexey Dobriyan <adobriyan@yandex-team.ru> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 2c3e4e2de699cd4d9f6c71f30a22d8f125cd6164) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-10hw/net/net_tx_pkt: Fix overrun in update_sctp_checksum()Philippe Mathieu-Daudé
If a fragmented packet size is too short, do not try to calculate its checksum. Reproduced using: $ cat << EOF | qemu-system-i386 -display none -nodefaults \ -machine q35,accel=qtest -m 32M \ -device igb,netdev=net0 \ -netdev user,id=net0 \ -qtest stdio outl 0xcf8 0x80000810 outl 0xcfc 0xe0000000 outl 0xcf8 0x80000804 outw 0xcfc 0x06 write 0xe0000403 0x1 0x02 writel 0xe0003808 0xffffffff write 0xe000381a 0x1 0x5b write 0xe000381b 0x1 0x00 EOF Assertion failed: (offset == 0), function iov_from_buf_full, file util/iov.c, line 39. #1 0x5575e81e952a in iov_from_buf_full qemu/util/iov.c:39:5 #2 0x5575e6500768 in net_tx_pkt_update_sctp_checksum qemu/hw/net/net_tx_pkt.c:144:9 #3 0x5575e659f3e1 in igb_setup_tx_offloads qemu/hw/net/igb_core.c:478:11 #4 0x5575e659f3e1 in igb_tx_pkt_send qemu/hw/net/igb_core.c:552:10 #5 0x5575e659f3e1 in igb_process_tx_desc qemu/hw/net/igb_core.c:671:17 #6 0x5575e659f3e1 in igb_start_xmit qemu/hw/net/igb_core.c:903:9 #7 0x5575e659f3e1 in igb_set_tdt qemu/hw/net/igb_core.c:2812:5 #8 0x5575e657d6a4 in igb_core_write qemu/hw/net/igb_core.c:4248:9 Fixes: CVE-2024-3567 Cc: qemu-stable@nongnu.org Reported-by: Zheyu Ma <zheyuma97@gmail.com> Fixes: f199b13bc1 ("igb: Implement Tx SCTP CSO") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2273 Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20240410070459.49112-1-philmd@linaro.org>
2024-04-10hw/net/lan9118: Fix overflow in MIL TX FIFOPhilippe Mathieu-Daudé
When the MAC Interface Layer (MIL) transmit FIFO is full, truncate the packet, and raise the Transmitter Error (TXE) flag. Broken since model introduction in commit 2a42499017 ("LAN9118 emulation"). When using the reproducer from https://gitlab.com/qemu-project/qemu/-/issues/2267 we get: hw/net/lan9118.c:798:17: runtime error: index 2048 out of bounds for type 'uint8_t[2048]' (aka 'unsigned char[2048]')     #0 0x563ec9a057b1 in tx_fifo_push hw/net/lan9118.c:798:43     #1 0x563ec99fbb28 in lan9118_writel hw/net/lan9118.c:1042:9     #2 0x563ec99f2de2 in lan9118_16bit_mode_write hw/net/lan9118.c:1205:9     #3 0x563ecbf78013 in memory_region_write_accessor system/memory.c:497:5     #4 0x563ecbf776f5 in access_with_adjusted_size system/memory.c:573:18     #5 0x563ecbf75643 in memory_region_dispatch_write system/memory.c:1521:16     #6 0x563ecc01bade in flatview_write_continue_step system/physmem.c:2713:18     #7 0x563ecc01b374 in flatview_write_continue system/physmem.c:2743:19     #8 0x563ecbff1c9b in flatview_write system/physmem.c:2774:12     #9 0x563ecbff1768 in address_space_write system/physmem.c:2894:18 ... [*] LAN9118 DS00002266B.pdf, Table 5.3.3 "INTERRUPT STATUS REGISTER" Cc: qemu-stable@nongnu.org Reported-by: Will Lester Reported-by: Chuhong Yuan <hslester96@gmail.com> Suggested-by: Peter Maydell <peter.maydell@linaro.org> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2267 Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20240409133801.23503-3-philmd@linaro.org>
2024-04-10hw/net/lan9118: Replace magic '2048' value by MIL_TXFIFO_SIZE definitionPhilippe Mathieu-Daudé
The magic 2048 is explained in the LAN9211 datasheet (DS00002414A) in chapter 1.4, "10/100 Ethernet MAC": The MAC Interface Layer (MIL), within the MAC, contains a 2K Byte transmit and a 128 Byte receive FIFO which is separate from the TX and RX FIFOs. [...] Note, the use of the constant in lan9118_receive() reveals that our implementation is using the same buffer for both tx and rx. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20240409133801.23503-2-philmd@linaro.org>
2024-04-09Revert "hw/virtio: Add support for VDPA network simulation devices"Michael S. Tsirkin
This reverts commit cd341fd1ffded978b2aa0b5309b00be7c42e347c. The patch adds non-upstream code in include/standard-headers/linux/virtio_pci.h which would make maintainance harder. Revert for now. Suggested-by: Jason Wang <jasowang@redhat.com> Message-Id: <df6b6b465753e754a19459e8cd61416548f89a42.1712569644.git.mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-04-02hw/net/virtio-net: fix qemu set used ring flag even vhost startedYajun Wu
When vhost-user or vhost-kernel is handling virtio net datapath, QEMU should not touch used ring. But with vhost-user socket reconnect scenario, in a very rare case (has pending kick event). VRING_USED_F_NO_NOTIFY is set by QEMU in following code path: #0 virtio_queue_split_set_notification (vq=0x7ff5f4c920a8, enable=0) at ../hw/virtio/virtio.c:511 #1 0x0000559d6dbf033b in virtio_queue_set_notification (vq=0x7ff5f4c920a8, enable=0) at ../hw/virtio/virtio.c:576 #2 0x0000559d6dbbbdbc in virtio_net_handle_tx_bh (vdev=0x559d703a6aa0, vq=0x7ff5f4c920a8) at ../hw/net/virtio-net.c:2801 #3 0x0000559d6dbf4791 in virtio_queue_notify_vq (vq=0x7ff5f4c920a8) at ../hw/virtio/virtio.c:2248 #4 0x0000559d6dbf79da in virtio_queue_host_notifier_read (n=0x7ff5f4c9211c) at ../hw/virtio/virtio.c:3525 #5 0x0000559d6d9a5814 in virtio_bus_cleanup_host_notifier (bus=0x559d703a6a20, n=1) at ../hw/virtio/virtio-bus.c:321 #6 0x0000559d6dbf83c9 in virtio_device_stop_ioeventfd_impl (vdev=0x559d703a6aa0) at ../hw/virtio/virtio.c:3774 #7 0x0000559d6d9a55c8 in virtio_bus_stop_ioeventfd (bus=0x559d703a6a20) at ../hw/virtio/virtio-bus.c:259 #8 0x0000559d6d9a53e8 in virtio_bus_grab_ioeventfd (bus=0x559d703a6a20) at ../hw/virtio/virtio-bus.c:199 #9 0x0000559d6dbf841c in virtio_device_grab_ioeventfd (vdev=0x559d703a6aa0) at ../hw/virtio/virtio.c:3783 #10 0x0000559d6d9bde18 in vhost_dev_enable_notifiers (hdev=0x559d707edd70, vdev=0x559d703a6aa0) at ../hw/virtio/vhost.c:1592 #11 0x0000559d6d89a0b8 in vhost_net_start_one (net=0x559d707edd70, dev=0x559d703a6aa0) at ../hw/net/vhost_net.c:266 #12 0x0000559d6d89a6df in vhost_net_start (dev=0x559d703a6aa0, ncs=0x559d7048d890, data_queue_pairs=31, cvq=0) at ../hw/net/vhost_net.c:412 #13 0x0000559d6dbb5b89 in virtio_net_vhost_status (n=0x559d703a6aa0, status=15 '\017') at ../hw/net/virtio-net.c:311 #14 0x0000559d6dbb5e34 in virtio_net_set_status (vdev=0x559d703a6aa0, status=15 '\017') at ../hw/net/virtio-net.c:392 #15 0x0000559d6dbb60d8 in virtio_net_set_link_status (nc=0x559d7048d890) at ../hw/net/virtio-net.c:455 #16 0x0000559d6da64863 in qmp_set_link (name=0x559d6f0b83d0 "hostnet1", up=true, errp=0x7ffdd76569f0) at ../net/net.c:1459 #17 0x0000559d6da7226e in net_vhost_user_event (opaque=0x559d6f0b83d0, event=CHR_EVENT_OPENED) at ../net/vhost-user.c:301 #18 0x0000559d6ddc7f63 in chr_be_event (s=0x559d6f2ffea0, event=CHR_EVENT_OPENED) at ../chardev/char.c:62 #19 0x0000559d6ddc7fdc in qemu_chr_be_event (s=0x559d6f2ffea0, event=CHR_EVENT_OPENED) at ../chardev/char.c:82 This issue causes guest kernel stop kicking device and traffic stop. Add vhost_started check in virtio_net_handle_tx_bh to fix this wrong VRING_USED_F_NO_NOTIFY set. Signed-off-by: Yajun Wu <yajunw@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20240402045109.97729-1-yajunw@nvidia.com> [PMD: Use unlikely()] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-03-29hw/net/net_tx_pkt: Fix virtio header without checksum offloadingAkihiko Odaki
It is incorrect to have the VIRTIO_NET_HDR_F_NEEDS_CSUM set when checksum offloading is disabled so clear the bit. TCP/UDP checksum is usually offloaded when the peer requires virtio headers because they can instruct the peer to compute checksum. However, igb disables TX checksum offloading when a VF is enabled whether the peer requires virtio headers because a transmitted packet can be routed to it and it expects the packet has a proper checksum. Therefore, it is necessary to have a correct virtio header even when checksum offloading is disabled. A real TCP/UDP checksum will be computed and saved in the buffer when checksum offloading is disabled. The virtio specification requires to set the packet checksum stored in the buffer to the TCP/UDP pseudo header when the VIRTIO_NET_HDR_F_NEEDS_CSUM bit is set so the bit must be cleared in that case. Fixes: ffbd2dbd8e64 ("e1000e: Perform software segmentation for loopback") Buglink: https://issues.redhat.com/browse/RHEL-23067 Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2024-03-29virtio-net: Fix vhost virtqueue notifiers for RSSAkihiko Odaki
virtio_net_guest_notifier_pending() and virtio_net_guest_notifier_mask() checked VIRTIO_NET_F_MQ to know there are multiple queues, but VIRTIO_NET_F_RSS also enables multiple queues. Refer to n->multiqueue, which is set to true either of VIRTIO_NET_F_MQ or VIRTIO_NET_F_RSS is enabled. Fixes: 68b0a6395f36 ("virtio-net: align ctrl_vq index for non-mq guest for vhost_vdpa") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2024-03-26vdpa-dev: Fix initialisation order to restore VDUSE compatibilityKevin Wolf
VDUSE requires that virtqueues are first enabled before the DRIVER_OK status flag is set; with the current API of the kernel module, it is impossible to enable the opposite order in our block export code because userspace is not notified when a virtqueue is enabled. This requirement also mathces the normal initialisation order as done by the generic vhost code in QEMU. However, commit 6c482547 accidentally changed the order for vdpa-dev and broke access to VDUSE devices with this. This changes vdpa-dev to use the normal order again and use the standard vhost callback .vhost_set_vring_enable for this. VDUSE devices can be used with vdpa-dev again after this fix. vhost_net intentionally avoided enabling the vrings for vdpa and does this manually later while it does enable them for other vhost backends. Reflect this in the vhost_net code and return early for vdpa, so that the behaviour doesn't change for this device. Cc: qemu-stable@nongnu.org Fixes: 6c4825476a43 ('vdpa: move vhost_vdpa_set_vring_ready to the caller') Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20240315155949.86066-1-kwolf@redhat.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2024-03-13Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Peter Maydell
into staging virtio,pc,pci: features, cleanups, fixes more memslots support in libvhost-user support PCIe Gen5/Gen6 link speeds in pcie more traces in vdpa network simulation devices support in vdpa SMBIOS type 9 descriptor implementation Bump max_cpus to 4096 vcpus in q35 aw-bits and granule options in VIRTIO-IOMMU Support report NUMA nodes for device memory using GI in acpi Beginning of shutdown event support in pvpanic fixes, cleanups all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # -----BEGIN PGP SIGNATURE----- # # iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmXw0TMPHG1zdEByZWRo # YXQuY29tAAoJECgfDbjSjVRp8x4H+gLMoGwaGAX7gDGPgn2Ix4j/3kO77ZJ9X9k/ # 1KqZu/9eMS1j2Ei+vZqf05w7qRjxxhwDq3ilEXF/+UFqgAehLqpRRB8j5inqvzYt # +jv0DbL11PBp/oFjWcytm5CbiVsvq8KlqCF29VNzc162XdtcduUOWagL96y8lJfZ # uPrOoyeR7SMH9lp3LLLHWgu+9W4nOS03RroZ6Umj40y5B7yR0Rrppz8lMw5AoQtr # 0gMRnFhYXeiW6CXdz+Tzcr7XfvkkYDi/j7ibiNSURLBfOpZa6Y8+kJGKxz5H1K1G # 6ZY4PBcOpQzl+NMrktPHogczgJgOK10t+1i/R3bGZYw2Qn/93Eg= # =C0UU # -----END PGP SIGNATURE----- # gpg: Signature made Tue 12 Mar 2024 22:03:31 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 * tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (68 commits) docs/specs/pvpanic: document shutdown event hw/cxl: Fix missing reserved data in CXL Device DVSEC hmat acpi: Fix out of bounds access due to missing use of indirection hmat acpi: Do not add Memory Proximity Domain Attributes Structure targetting non existent memory. qemu-options.hx: Document the virtio-iommu-pci aw-bits option hw/arm/virt: Set virtio-iommu aw-bits default value to 48 hw/i386/q35: Set virtio-iommu aw-bits default value to 39 virtio-iommu: Add an option to define the input range width virtio-iommu: Trace domain range limits as unsigned int qemu-options.hx: Document the virtio-iommu-pci granule option virtio-iommu: Change the default granule to the host page size virtio-iommu: Add a granule property hw/i386/acpi-build: Add support for SRAT Generic Initiator structures hw/acpi: Implement the SRAT GI affinity structure qom: new object to associate device to NUMA node hw/i386/pc: Inline pc_cmos_init() into pc_cmos_init_late() and remove it hw/i386/pc: Set "normal" boot device order in pc_basic_device_init() hw/i386/pc: Avoid one use of the current_machine global hw/i386/pc: Remove "rtc_state" link again Revert "hw/i386/pc: Confine system flash handling to pc_sysfw" ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org> # Conflicts: # hw/core/machine.c
2024-03-12hw/pci: Always call pcie_sriov_pf_reset()Akihiko Odaki
Call pcie_sriov_pf_reset() from pci_do_device_reset() just as we do for msi_reset() and msix_reset() to prevent duplicating code for each SR-IOV PF. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20240228-reuse-v8-5-282660281e60@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Sriram Yagnaraman <sriram.yagnaraman@ericsson.com>
2024-03-12pcie_sriov: Reset SR-IOV extended capabilityAkihiko Odaki
pcie_sriov_pf_disable_vfs() is called when resetting the PF, but it only disables VFs and does not reset SR-IOV extended capability, leaking the state and making the VF Enable register inconsistent with the actual state. Replace pcie_sriov_pf_disable_vfs() with pcie_sriov_pf_reset(), which does not only disable VFs but also resets the capability. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20240228-reuse-v8-3-282660281e60@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Sriram Yagnaraman <sriram.yagnaraman@ericsson.com>
2024-03-12hw/virtio: Add support for VDPA network simulation devicesHao Chen
This patch adds support for VDPA network simulation devices. The device is developed based on virtio-net and tap backend, and supports hardware live migration function. For more details, please refer to "docs/system/devices/vdpa-net.rst" Signed-off-by: Hao Chen <chenh@yusur.tech> Message-Id: <20240221073802.2888022-1-chenh@yusur.tech> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12virtio-net: Added property to load eBPF RSS with fds.Andrew Melnychenko
eBPF RSS program and maps may now be passed during initialization. Initially was implemented for libvirt to launch qemu without permissions, and initialized eBPF program through the helper. Signed-off-by: Andrew Melnychenko <andrew@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2024-03-12Avoid unaligned fetch in ladr_match()Nick Briggs
There is no guarantee that the PCNetState is allocated such that csr[8] is allocated on an 8-byte boundary. Since not all hosts are capable of unaligned fetches the 16-bit elements need to be fetched individually to avoid a potential fault. Closes issue #2143 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2143 Signed-off-by: Nick Briggs <nicholas.h.briggs@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jason Wang <jasowang@redhat.com>
2024-03-12e1000e: fix link state on resumeLaurent Vivier
On resume e1000e_vm_state_change() always calls e1000e_autoneg_resume() that sets link_down to false, and thus activates the link even if we have disabled it. The problem can be reproduced starting qemu in paused state (-S) and then set the link to down. When we resume the machine the link appears to be up. Reproducer: # qemu-system-x86_64 ... -device e1000e,netdev=netdev0,id=net0 -S {"execute": "qmp_capabilities" } {"execute": "set_link", "arguments": {"name": "net0", "up": false}} {"execute": "cont" } To fix the problem, merge the content of e1000e_vm_state_change() into e1000e_core_post_load() as e1000 does. Buglink: https://issues.redhat.com/browse/RHEL-21867 Fixes: 6f3fbe4ed06a ("net: Introduce e1000e device emulation") Suggested-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2024-03-12igb: fix link state on resumeLaurent Vivier
On resume igb_vm_state_change() always calls igb_autoneg_resume() that sets link_down to false, and thus activates the link even if we have disabled it. The problem can be reproduced starting qemu in paused state (-S) and then set the link to down. When we resume the machine the link appears to be up. Reproducer: # qemu-system-x86_64 ... -device igb,netdev=netdev0,id=net0 -S {"execute": "qmp_capabilities" } {"execute": "set_link", "arguments": {"name": "net0", "up": false}} {"execute": "cont" } To fix the problem, merge the content of igb_vm_state_change() into igb_core_post_load() as e1000 does. Buglink: https://issues.redhat.com/browse/RHEL-21867 Fixes: 3a977deebe6b ("Intrdocue igb device emulation") Cc: akihiko.odaki@daynix.com Suggested-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2024-03-09hw/net/xen_nic: Fix missing ERRP_GUARD() for error_prepend()Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. ERRP_GUARD() could avoid the case when @errp is the pointer of error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1]. The xen_netdev_connect() passes @errp to error_prepend(), and its @errp parameter is from xen_device_frontend_changed(). Though its @errp points to @local_err of xen_device_frontend_changed(), to follow the requirement of @errp, add missing ERRP_GUARD() at the beginning of this function. [1]: Issue description in the commit message of commit ae7c80a7bd73 ("error: New macro ERRP_GUARD()"). Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Paul Durrant <paul@xen.org> Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20240229143914.1977550-3-zhao1.liu@linux.intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-02-28migration: MigrationNotifyFuncSteve Sistare
Define MigrationNotifyFunc to improve type safety and simplify migration notifiers. Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/1708622920-68779-7-git-send-email-steven.sistare@oracle.com Signed-off-by: Peter Xu <peterx@redhat.com>
2024-02-28migration: MigrationEvent for notifiersSteve Sistare
Passing MigrationState to notifiers is unsound because they could access unstable migration state internals or even modify the state. Instead, pass the minimal info needed in a new MigrationEvent struct, which could be extended in the future if needed. Suggested-by: Peter Xu <peterx@redhat.com> Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/1708622920-68779-5-git-send-email-steven.sistare@oracle.com Signed-off-by: Peter Xu <peterx@redhat.com>
2024-02-28migration: convert to NotifierWithReturnSteve Sistare
Change all migration notifiers to type NotifierWithReturn, so notifiers can return an error status in a future patch. For now, pass NULL for the notifier error parameter, and do not check the return value. Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/1708622920-68779-4-git-send-email-steven.sistare@oracle.com [peterx: dropped unexpected update to roms/seabios-hppa] Signed-off-by: Peter Xu <peterx@redhat.com>
2024-02-11hw/net/tulip: add chip status register valuesSven Schnelle
Netbsd isn't able to detect a link on the emulated tulip card. That's because netbsd reads the Chip Status Register of the Phy (address 0x14). The default phy data in the qemu tulip driver is all zero, which means no link is established and autonegotation isn't complete. Therefore set the register to 0x3b40, which means: Link is up, Autonegotation complete, Full Duplex, 100MBit/s Link speed. Also clear the mask because this register is read only. Signed-off-by: Sven Schnelle <svens@stackframe.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Helge Deller <deller@gmx.de> Tested-by: Helge Deller <deller@gmx.de> Signed-off-by: Helge Deller <deller@gmx.de>
2024-02-02Merge tag 'pull-target-arm-20240202' of ↵Peter Maydell
https://git.linaro.org/people/pmaydell/qemu-arm into staging target/arm: fix exception syndrome for AArch32 bkpt insn pci, vmbus, adb, s390x/css-bridge: Switch buses to 3-phase reset system/vl.c: Fix handling of '-serial none -serial something' target/arm: Add ID_AA64ZFR0_EL1.B16B16 to the exposed-to-userspace set tests/qtest/xlnx-versal-trng-test.c: Drop use of variable length array target/arm: Reinstate "vfp" property on AArch32 CPUs doc/sphinx/hxtool.py: add optional label argument to SRST directive hw/arm: Check for CPU types in machine_run_board_init() for various boards pci-host: designware: Limit value range of iATU viewport register hw/arm: Convert some DPRINTF macros to trace events and guest errors hw/arm: NPCM7XX SoC: Add GMAC ethernet controller devices hw/arm: Implement BCM2835 SPI Controller # -----BEGIN PGP SIGNATURE----- # # iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmW9C84ZHHBldGVyLm1h # eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3qS6D/wM0/JGEYfaadpuMEOAx4PG # AnfScbPqVhx9J31P2Ks3VrB5F108aq/SaL2BmCb3BLF/ECChlhBXIjd7ukdHstts # F1TvqtvLGDZQz6wSVUeB0YOvAjGa3vIskn+Xvk9e6Ne6PcXgVnxAof/cPsXUiYNy # 6DJjNiLJ/a9Xgq9rjFO6vzW3AL95U6/FmD2F0pOotWXERhNhoyYVV6RtyeqKlDQP # yFVk5h601YURk9PeNZn9zpOpZqjAM7PxyF3X50N3Sv+G0uoKSr6b+c3/fDJbJo3+ # 0LXomEa8hdheQxm1dLY5OD0JX3bvYxwH41bDg9B0iEdjxUdXt6LfXI9Nvw9BAwix # 8AcGJJUaL4XU4uPfHBpRJApM15+MRb0hqfv4ZcGk8e67IIqVeDbKL2clTQGoHSg1 # KaB0POhtFx//M/uBOyk/FR2gb2eBNU8GuoCgxdDwh0K5ylcaK1YPiX4Tcglu4iS0 # Frvazphb2pO1BK6JiJwN2/9ezzDkDJqTKoSqdc4g3ETVOGnxr+tXwcds3t2iK3g2 # y+pgijDOAT3bJO5kYeGvhoEJPKqXwJ3UQ8zTJsU2XSYwBjIyv5V3oOn6elwYJaWq # yUDTC3QEK61KfnQnfTyLfdGWX1aVzHnYLWmQdO+3cczuQU0s0MP246Z1GAgDtgvD # jGjDBz6mryWvP2H0xSmERQ== # =azdP # -----END PGP SIGNATURE----- # gpg: Signature made Fri 02 Feb 2024 15:35:42 GMT # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate] # gpg: aka "Peter Maydell <peter@archaic.org.uk>" [ultimate] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * tag 'pull-target-arm-20240202' of https://git.linaro.org/people/pmaydell/qemu-arm: (36 commits) hw/arm: Connect SPI Controller to BCM2835 hw/ssi: Implement BCM2835 SPI Controller tests/qtest: Adding PCS Module test to GMAC Qtest hw/net: GMAC Tx Implementation hw/net: GMAC Rx Implementation tests/qtest: Creating qtest for GMAC Module hw/arm: Add GMAC devices to NPCM7XX SoC hw/net: Add NPCMXXX GMAC device hw/xen: convert stderr prints to error/warn reports hw/xen/xen-hvm-common.c: convert DPRINTF to tracepoints hw/xen/xen-mapcache.c: convert DPRINTF to tracepoints hw/arm/xen_arm.c: convert DPRINTF to trace events and error/warn reports hw/arm/z2: convert DPRINTF to trace events and guest errors hw/arm/strongarm.c: convert DPRINTF to trace events and guest errors pci-host: designware: Limit value range of iATU viewport register hw/arm/zynq: Check for CPU types in machine_run_board_init() hw/arm/vexpress: Check for CPU types in machine_run_board_init() hw/arm/npcm7xx_boards: Simplify setting MachineClass::valid_cpu_types[] hw/arm/musca: Simplify setting MachineClass::valid_cpu_types[] hw/arm/msf2: Simplify setting MachineClass::valid_cpu_types[] ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-02-02hw/net/lasi_i82596: use qemu_create_nic_device()David Woodhouse
Create the device only if there is a corresponding NIC config for it. Remove the explicit check on nd_table[0].used from hw/hppa/machine.c which (since commit d8a3220005d7) tries to do the same thing. The lasi_82596 support has been disabled since it was first introduced, since enable_lasi_lan() has always been zero. This allows the user to enable it by explicitly requesting a NIC model 'lasi_82596' or just using the alias 'lasi'. Otherwise, it defaults to a PCI NIC as before. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Thomas Huth <thuth@redhat.com>
2024-02-02hw/net/lasi_i82596: Re-enable buildDavid Woodhouse
When converting to the shiny build-system-du-jour, a typo prevented the last_i82596 driver from being built. Correct the config option name to re-enable the build. And include "sysemu/sysemu.h" so it actually builds. Fixes: b1419fa66558 ("meson: convert hw/net") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2144 Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Thomas Huth <thuth@redhat.com>
2024-02-02hw/net/etraxfs-eth: use qemu_configure_nic_device()David Woodhouse
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Thomas Huth <thuth@redhat.com>
2024-02-02hw/net/lan9118: use qemu_configure_nic_device()David Woodhouse
Some callers instantiate the device unconditionally, others will do so only if there is a NICInfo to go with it. This appears to be fairly random, but preseve the existing behaviour for now. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Thomas Huth <thuth@redhat.com>
2024-02-02hw/net/smc91c111: use qemu_configure_nic_device()David Woodhouse
Some callers instantiate the device unconditionally, others will do so only if there is a NICInfo to go with it. This appears to be fairly random, but preserve the existing behaviour of each caller for now. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Thomas Huth <thuth@redhat.com>
2024-02-02hw/net: GMAC Tx ImplementationNabih Estefan Diaz
- Implementation of Transmit function for packets - Implementation for reading and writing from and to descriptors in memory for Tx Added relevant trace-events NOTE: This function implements the steps detailed in the datasheet for transmitting messages from the GMAC. Change-Id: Icf14f9fcc6cc7808a41acd872bca67c9832087e6 Signed-off-by: Nabih Estefan <nabihestefan@google.com> Reviewed-by: Tyrone Ting <kfting@nuvoton.com> Message-id: 20240131002800.989285-6-nabihestefan@google.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-02-02hw/net: GMAC Rx ImplementationNabih Estefan Diaz
- Implementation of Receive function for packets - Implementation for reading and writing from and to descriptors in memory for Rx When RX starts, we need to flush the queued packets so that they can be received by the GMAC device. Without this it won't work with TAP NIC device. When RX descriptor list is full, it returns a DMA_STATUS for software to handle it. But there's no way to indicate the software has handled all RX descriptors and the whole pipeline stalls. We do something similar to NPCM7XX EMC to handle this case. 1. Return packet size when RX descriptor is full, effectively dropping these packets in such a case. 2. When software clears RX descriptor full bit, continue receiving further packets by flushing QEMU packet queue. Added relevant trace-events Change-Id: I132aa254a94cda1a586aba2ea33bbfc74ecdb831 Signed-off-by: Hao Wu <wuhaotsh@google.com> Signed-off-by: Nabih Estefan <nabihestefan@google.com> Reviewed-by: Tyrone Ting <kfting@nuvoton.com> Message-id: 20240131002800.989285-5-nabihestefan@google.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-02-02hw/net: Add NPCMXXX GMAC deviceHao Wu
This patch implements the basic registers of GMAC device and sets registers for networking functionalities. Squashed IRQ Implementation patch into this one for compliation. Tested: The following message shows up with the change: Broadcom BCM54612E stmmac-0:00: attached PHY driver [Broadcom BCM54612E] (mii_bus:phy_addr=stmmac-0:00, irq=POLL) stmmaceth f0802000.eth eth0: Link is Up - 1Gbps/Full - flow control rx/tx Change-Id: If71c6d486b95edcccba109ba454870714d7e0940 Signed-off-by: Hao Wu <wuhaotsh@google.com> Signed-off-by: Nabih Estefan Diaz <nabihestefan@google.com> Reviewed-by: Tyrone Ting <kfting@nuvoton.com> Message-id: 20240131002800.989285-2-nabihestefan@google.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-01-25virtio-net: correctly copy vnet header when flushing TXJason Wang
When HASH_REPORT is negotiated, the guest_hdr_len might be larger than the size of the mergeable rx buffer header. Using virtio_net_hdr_mrg_rxbuf during the header swap might lead a stack overflow in this case. Fixing this by using virtio_net_hdr_v1_hash instead. Reported-by: Xiao Lei <leixiao.nop@zju.edu.cn> Cc: Yuri Benditovich <yuri.benditovich@daynix.com> Cc: qemu-stable@nongnu.org Cc: Mauro Matteo Cascella <mcascell@redhat.com> Fixes: CVE-2023-6693 Fixes: e22f0603fb2f ("virtio-net: reference implementation of hash report") Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Jason Wang <jasowang@redhat.com>
2024-01-08system/cpus: rename qemu_mutex_lock_iothread() to bql_lock()Stefan Hajnoczi
The Big QEMU Lock (BQL) has many names and they are confusing. The actual QemuMutex variable is called qemu_global_mutex but it's commonly referred to as the BQL in discussions and some code comments. The locking APIs, however, are called qemu_mutex_lock_iothread() and qemu_mutex_unlock_iothread(). The "iothread" name is historic and comes from when the main thread was split into into KVM vcpu threads and the "iothread" (now called the main loop thread). I have contributed to the confusion myself by introducing a separate --object iothread, a separate concept unrelated to the BQL. The "iothread" name is no longer appropriate for the BQL. Rename the locking APIs to: - void bql_lock(void) - void bql_unlock(void) - bool bql_locked(void) There are more APIs with "iothread" in their names. Subsequent patches will rename them. There are also comments and documentation that will be updated in later patches. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Paul Durrant <paul@xen.org> Acked-by: Fabiano Rosas <farosas@suse.de> Acked-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Cédric Le Goater <clg@kaod.org> Acked-by: Peter Xu <peterx@redhat.com> Acked-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Acked-by: Hyman Huang <yong.huang@smartx.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-id: 20240102153529.486531-2-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2024-01-05hw/net: cadence_gem: Fix MDIO_OP_xxx valuesBin Meng
Testing upstream U-Boot with 'sifive_u' machine we see: => dhcp ethernet@10090000: PHY present at 0 Could not get PHY for ethernet@10090000: addr 0 phy_connect failed This has been working till QEMU 8.1 but broken since QEMU 8.2. Fixes: 1b09eeb122aa ("hw/net/cadence_gem: use FIELD to describe PHYMNTNC register fields") Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-05hw/net/can/sja1000: fix bug for single acceptance filter and standard framePavel Pisa
A CAN sja1000 standard frame filter mask has been computed and applied incorrectly for standard frames when single Acceptance Filter Mode (MOD_AFM = 1) has been selected. The problem has not been found by Linux kernel testing because it uses dual filter mode (MOD_AFM = 0) and leaves falters fully open. The problem has been noticed by Grant Ramsay when testing with Zephyr RTOS which uses single filter mode. Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Reported-by: Grant Ramsay <gramsay@enphaseenergy.com> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2028 Fixes: 733210e754 ("hw/net/can: SJA1000 chip register level emulation") Message-ID: <20240103231426.5685-1-pisa@fel.cvut.cz>
2024-01-04Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into stagingPeter Maydell
* configure: use a native non-cross compiler for linux-user * meson: cleanups * target/i386: miscellaneous cleanups and optimizations * target/i386: implement CMPccXADD * target/i386: the sgx_epc_get_section stub is reachable * esp: check for NULL result from scsi_device_find() # -----BEGIN PGP SIGNATURE----- # # iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmWRImYUHHBib256aW5p # QHJlZGhhdC5jb20ACgkQv/vSX3jHroNd7AgAgcyJGiMfUkXqhefplpm06RDXQIa8 # FuoJqPb21lO75DQKfaFRAc4xGLagjJROMJGHMm9HvMu2VlwvOydkQlfFRspENxQ/ # 5XzGdb/X0A7HA/mwUfnMB1AZx0Vs32VI5IBSc6acc9fmgeZ84XQEoM3KBQHUik7X # mSkE4eltR9gJ+4IaGo4voZtK+YoVD8nEcuqmnKihSPWizev0FsZ49aNMtaYa9qC/ # Xs3kiQd/zPibHDHJu0ulFsNZgxtUcvlLHTCf8gO4dHWxCFLXGubMush83McpRtNB # Qoh6cTLH+PBXfrxMR3zmTZMNvo8Euls3s07Y8TkNP4vdIIE/kMeMDW1wJw== # =mq30 # -----END PGP SIGNATURE----- # gpg: Signature made Sun 31 Dec 2023 08:12:22 GMT # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * tag 'for-upstream' of https://gitlab.com/bonzini/qemu: (46 commits) meson.build: report graphics backends separately configure, meson: rename targetos to host_os meson: rename config_all meson: remove CONFIG_ALL meson: remove config_targetos meson: remove CONFIG_POSIX and CONFIG_WIN32 from config_targetos meson: remove OS definitions from config_targetos meson: always probe u2f and canokey if the option is enabled meson: move subdirs to "Collect sources" section meson: move config-host.h definitions together meson: move CFI detection code with other compiler flags meson: keep subprojects together meson: move accelerator dependency checks together meson: move option validation together meson: move program checks together meson: add more sections to main meson.build configure: unify again the case arms in probe_target_compiler configure: remove unnecessary subshell Makefile: clean qemu-iotests output meson: use version_compare() to compare version ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2023-12-31meson: remove CONFIG_ALLPaolo Bonzini
CONFIG_ALL is tricky to use and was ported over to Meson from the recursive processing of Makefile variables. Meson sourcesets however have all_sources() and all_dependencies() methods that remove the need for it. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-12-30hw/net: Constify VMStateRichard Henderson
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231221031652.119827-42-richard.henderson@linaro.org>
2023-11-27hw/net/can/xlnx-zynqmp: Avoid underflow while popping RX FIFOPhilippe Mathieu-Daudé
Per https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/Message-Format Message Format The same message format is used for RXFIFO, TXFIFO, and TXHPB. Each message includes four words (16 bytes). Software must read and write all four words regardless of the actual number of data bytes and valid fields in the message. There is no mention in this reference manual about what the hardware does when not all four words are read. To fix the reported underflow behavior, I choose to fill the 4 frame data registers when the first register (ID) is accessed, which is how I expect hardware would do. Reported-by: Qiang Liu <cyruscyliu@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com> Reviewed-by: Vikram Garhwal <vikram.garhwal@amd.com> Message-id: 20231124183325.95392-3-philmd@linaro.org Fixes: 98e5d7a2b7 ("hw/net/can: Introduce Xilinx ZynqMP CAN controller") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1427 Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com> Reviewed-by: Vikram Garhwal <vikram.garhwal@amd.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2023-11-27hw/net/can/xlnx-zynqmp: Avoid underflow while popping TX FIFOsPhilippe Mathieu-Daudé
Per https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/Message-Format Message Format The same message format is used for RXFIFO, TXFIFO, and TXHPB. Each message includes four words (16 bytes). Software must read and write all four words regardless of the actual number of data bytes and valid fields in the message. There is no mention in this reference manual about what the hardware does when not all four words are written. To fix the reported underflow behavior when DATA2 register is written, I choose to fill the data with the previous content of the ID / DLC / DATA1 registers, which is how I expect hardware would do. Note there is no hardware flag raised under such condition. Reported-by: Qiang Liu <cyruscyliu@gmail.com> Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com> Reviewed-by: Vikram Garhwal <vikram.garhwal@amd.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20231124183325.95392-2-philmd@linaro.org Fixes: 98e5d7a2b7 ("hw/net/can: Introduce Xilinx ZynqMP CAN controller") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1425 Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com> Reviewed-by: Vikram Garhwal <vikram.garhwal@amd.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2023-11-21net: Provide MemReentrancyGuard * to qemu_new_nic()Akihiko Odaki
Recently MemReentrancyGuard was added to DeviceState to record that the device is engaging in I/O. The network device backend needs to update it when delivering a packet to a device. In preparation for such a change, add MemReentrancyGuard * as a parameter of qemu_new_nic(). Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Jason Wang <jasowang@redhat.com>
2023-11-15hw/net/cadence_gem.c: spelling fixes: OctectsMichael Tokarev
Fixes: c755c943aa2e "hw/net/cadence_gem: use REG32 macro for register definitions" Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Luc Michel <luc.michel@amd.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-13igb: Add Function Level Reset to PF and VFCédric Le Goater
The Intel 82576EB GbE Controller say that the Physical and Virtual Functions support Function Level Reset. Add the capability to the PF device model using device property "x-pcie-flr-init" which is "on" by default and "off" for machines <= 8.1 to preserve compatibility. The FLR capability of the VF model is defined according to the FLR property of the PF, this to avoid adding an extra compatibility property. Cc: Sriram Yagnaraman <sriram.yagnaraman@est.tech> Fixes: 3a977deebe6b ("Intrdocue igb device emulation") Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2023-11-13igb: Add a VF reset handlerCédric Le Goater
Export the igb_vf_reset() helper routine from the PF model to let the IGBVF model implement its own device reset. Cc: Akihiko Odaki <akihiko.odaki@daynix.com> Suggested-by: Sriram Yagnaraman <sriram.yagnaraman@est.tech> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2023-11-07hw/xen: update Xen PV NIC to XenDevice modelDavid Woodhouse
This allows us to use Xen PV networking with emulated Xen guests, and to add them on the command line or hotplug. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-11-01migration: Use vmstate_register_any()Juan Quintela
This are the easiest cases, where we were already using VMSTATE_INSTANCE_ID_ANY. Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231020090731.28701-3-quintela@redhat.com>
2023-10-27hw/net/cadence_gem: enforce 32 bits variable size for CRCLuc Michel
The CRC was stored in an unsigned variable in gem_receive. Change it for a uint32_t to ensure we have the correct variable size here. Signed-off-by: Luc Michel <luc.michel@amd.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: sai.pavan.boddu@amd.com Message-id: 20231017194422.4124691-12-luc.michel@amd.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2023-10-27hw/net/cadence_gem: perform PHY access on write onlyLuc Michel
The MDIO access is done only on a write to the PHYMNTNC register. A subsequent read is used to retrieve the result but does not trigger an MDIO access by itself. Refactor the PHY access logic to perform all accesses (MDIO reads and writes) at PHYMNTNC write time. Signed-off-by: Luc Michel <luc.michel@amd.com> Reviewed-by: sai.pavan.boddu@amd.com Message-id: 20231017194422.4124691-11-luc.michel@amd.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2023-10-27hw/net/cadence_gem: use FIELD to describe PHYMNTNC register fieldsLuc Michel
Use the FIELD macro to describe the PHYMNTNC register fields. Signed-off-by: Luc Michel <luc.michel@amd.com> Reviewed-by: sai.pavan.boddu@amd.com Message-id: 20231017194422.4124691-10-luc.michel@amd.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2023-10-27hw/net/cadence_gem: use FIELD to describe DESCONF6 register fieldsLuc Michel
Use the FIELD macro to describe the DESCONF6 register fields. Signed-off-by: Luc Michel <luc.michel@amd.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20231017194422.4124691-9-luc.michel@amd.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>