aboutsummaryrefslogtreecommitdiff
path: root/rust/qemu-api-macros/src
diff options
context:
space:
mode:
authorThomas Huth <thuth@redhat.com>2025-01-16 12:58:25 +0100
committerThomas Huth <thuth@redhat.com>2025-01-22 08:28:49 +0100
commit68c95ed1db070f7545e487e742715f01a545aab0 (patch)
tree2ad7cea4290873a7ff31bdce23207b166f716c54 /rust/qemu-api-macros/src
parent3936d0556383829b8db9518aed8badfed6513953 (diff)
downloadqemu-68c95ed1db070f7545e487e742715f01a545aab0.zip
qemu-68c95ed1db070f7545e487e742715f01a545aab0.tar.gz
qemu-68c95ed1db070f7545e487e742715f01a545aab0.tar.bz2
pc-bios/s390-ccw: Fix boot problem with virtio-net devices
When we are trying to boot from virtio-net devices, the s390-ccw bios currently leaves the virtio-net device enabled after using it. That means that the receiving virt queues will continue to happily write incoming network packets into memory. This can corrupt data of the following boot process. For example, if you set up a second guest on a virtual network and create a lot of broadcast traffic there, e.g. with: ping -i 0.02 -s 1400 -b 192.168.1.255 and then you try to boot a guest with two boot devices, a network device first (which should not be bootable) and e.g. a bootable SCSI CD second, then this guest will fail to load the kernel from the CD image: $ qemu-system-s390x -m 2G -nographic -device virtio-scsi-ccw \ -netdev tap,id=net0 -device virtio-net-ccw,netdev=net0,bootindex=1 \ -drive if=none,file=test.iso,format=raw,id=cd1 \ -device scsi-cd,drive=cd1,bootindex=2 LOADPARM=[ ] Network boot device detected Network boot starting... Using MAC address: 52:54:00:12:34:56 Requesting information via DHCP: done Using IPv4 address: 192.168.1.76 Using TFTP server: 192.168.1.1 Trying pxelinux.cfg files... TFTP error: ICMP ERROR "port unreachable" Receiving data: 0 KBytes Repeating TFTP read request... TFTP error: ICMP ERROR "port unreachable" Failed to load OS from network. Failed to IPL from this network! LOADPARM=[ ] Using virtio-scsi. ! virtio-scsi:setup:inquiry: response VS RESP=ff ! ERROR: No suitable device for IPL. Halting... We really have to shut up the virtio-net devices after we're not using it anymore. The easiest way to do this is to simply reset the device, so let's do that now. Reviewed-by: Jared Rossi <jrossi@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Tested-by: Jared Rossi <jrossi@linux.ibm.com> Message-ID: <20250116115826.192047-3-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Diffstat (limited to 'rust/qemu-api-macros/src')
0 files changed, 0 insertions, 0 deletions