* Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest @ 2021-03-25 17:19 Howard Spoelstra 2021-03-25 17:34 ` Peter Maydell 0 siblings, 1 reply; 12+ messages in thread From: Howard Spoelstra @ 2021-03-25 17:19 UTC (permalink / raw) To: qemu-devel qemu-devel Hi, When running qemu-system-ppc with Mac OS guest, the guest crashes when using a tap network connection. Openvpn 2.4.9-I601-win10 is installed with TAP-Windows 9.24.2. A tap connection called TapQemu is bridged with the default ethernet connection. It gets activated when I start qemu. To reproduce, compile qemu-system-ppc from current source and run: qemu-system-ppc.exe ^ -L pc-bios ^ -M mac99 ^ -m 128 ^ -sdl -serial stdio ^ -boot c ^ -drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^ -device sungem,netdev=network01 -netdev tap,ifname=TapQemu,id=network01 I bisected to the commit below. Thanks for looking into this. Best, Howard 969e50b61a285b0cc8dea6d4d2ade3f758d5ecc7 is the first bad commit commit 969e50b61a285b0cc8dea6d4d2ade3f758d5ecc7 Author: Bin Meng <bmeng.cn@gmail.com> Date: Wed Mar 17 14:26:29 2021 +0800 net: Pad short frames to minimum size before sending from SLiRP/TAP The minimum Ethernet frame length is 60 bytes. For short frames with smaller length like ARP packets (only 42 bytes), on a real world NIC it can choose either padding its length to the minimum required 60 bytes, or sending it out directly to the wire. Such behavior can be hardcoded or controled by a register bit. Similarly on the receive path, NICs can choose either dropping such short frames directly or handing them over to software to handle. On the other hand, for the network backends like SLiRP/TAP, they don't expose a way to control the short frame behavior. As of today they just send/receive data from/to the other end connected to them, which means any sized packet is acceptable. So they can send and receive short frames without any problem. It is observed that ARP packets sent from SLiRP/TAP are 42 bytes, and SLiRP/TAP just send these ARP packets to the other end which might be a NIC model that does not allow short frames to pass through. To provide better compatibility, for packets sent from QEMU network backends like SLiRP/TAP, we change to pad short frames before sending it out to the other end, if the other end does not forbid it via the nc->do_not_pad flag. This ensures a backend as an Ethernet sender does not violate the spec. But with this change, the behavior of dropping short frames from SLiRP/TAP interfaces in the NIC model cannot be emulated because it always receives a packet that is spec complaint. The capability of sending short frames from NIC models is still supported and short frames can still pass through SLiRP/TAP. This commit should be able to fix the issue as reported with some NIC models before, that ARP requests get dropped, preventing the guest from becoming visible on the network. It was workarounded in these NIC models on the receive path, that when a short frame is received, it is padded up to 60 bytes. The following 2 commits seem to be the one to workaround this issue in e1000 and vmxenet3 before, and should probably be reverted. commit 78aeb23eded2 ("e1000: Pad short frames to minimum size (60 bytes)") commit 40a87c6c9b11 ("vmxnet3: Pad short frames to minimum size (60 bytes)") Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> net/slirp.c | 10 ++++++++++ net/tap-win32.c | 10 ++++++++++ net/tap.c | 10 ++++++++++ 3 files changed, 30 insertions(+) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest 2021-03-25 17:19 Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest Howard Spoelstra @ 2021-03-25 17:34 ` Peter Maydell 2021-03-26 1:50 ` Bin Meng 0 siblings, 1 reply; 12+ messages in thread From: Peter Maydell @ 2021-03-25 17:34 UTC (permalink / raw) To: Howard Spoelstra; +Cc: Jason Wang, Bin Meng, qemu-devel qemu-devel (adding the relevant people to the cc list) On Thu, 25 Mar 2021 at 17:26, Howard Spoelstra <hsp.cat7@gmail.com> wrote: > > Hi, > > When running qemu-system-ppc with Mac OS guest, the guest crashes when > using a tap network connection. Openvpn 2.4.9-I601-win10 is installed > with TAP-Windows 9.24.2. A tap connection called TapQemu is bridged > with the default ethernet connection. It gets activated when I start > qemu. > > To reproduce, compile qemu-system-ppc from current source and run: > > qemu-system-ppc.exe ^ > -L pc-bios ^ > -M mac99 ^ > -m 128 ^ > -sdl -serial stdio ^ > -boot c ^ > -drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^ > -device sungem,netdev=network01 -netdev tap,ifname=TapQemu,id=network01 > > I bisected to the commit below. Thanks for looking into this. > > Best, > Howard > > 969e50b61a285b0cc8dea6d4d2ade3f758d5ecc7 is the first bad commit > commit 969e50b61a285b0cc8dea6d4d2ade3f758d5ecc7 > Author: Bin Meng <bmeng.cn@gmail.com> > Date: Wed Mar 17 14:26:29 2021 +0800 > > net: Pad short frames to minimum size before sending from SLiRP/TAP > > The minimum Ethernet frame length is 60 bytes. For short frames with > smaller length like ARP packets (only 42 bytes), on a real world NIC > it can choose either padding its length to the minimum required 60 > bytes, or sending it out directly to the wire. Such behavior can be > hardcoded or controled by a register bit. Similarly on the receive > path, NICs can choose either dropping such short frames directly or > handing them over to software to handle. > > On the other hand, for the network backends like SLiRP/TAP, they > don't expose a way to control the short frame behavior. As of today > they just send/receive data from/to the other end connected to them, > which means any sized packet is acceptable. So they can send and > receive short frames without any problem. It is observed that ARP > packets sent from SLiRP/TAP are 42 bytes, and SLiRP/TAP just send > these ARP packets to the other end which might be a NIC model that > does not allow short frames to pass through. > > To provide better compatibility, for packets sent from QEMU network > backends like SLiRP/TAP, we change to pad short frames before sending > it out to the other end, if the other end does not forbid it via the > nc->do_not_pad flag. This ensures a backend as an Ethernet sender > does not violate the spec. But with this change, the behavior of > dropping short frames from SLiRP/TAP interfaces in the NIC model > cannot be emulated because it always receives a packet that is spec > complaint. The capability of sending short frames from NIC models is > still supported and short frames can still pass through SLiRP/TAP. > > This commit should be able to fix the issue as reported with some > NIC models before, that ARP requests get dropped, preventing the > guest from becoming visible on the network. It was workarounded in > these NIC models on the receive path, that when a short frame is > received, it is padded up to 60 bytes. > > The following 2 commits seem to be the one to workaround this issue > in e1000 and vmxenet3 before, and should probably be reverted. > > commit 78aeb23eded2 ("e1000: Pad short frames to minimum size (60 bytes)") > commit 40a87c6c9b11 ("vmxnet3: Pad short frames to minimum size > (60 bytes)") > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com> > Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> > Signed-off-by: Jason Wang <jasowang@redhat.com> > > net/slirp.c | 10 ++++++++++ > net/tap-win32.c | 10 ++++++++++ > net/tap.c | 10 ++++++++++ > 3 files changed, 30 insertions(+) > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest 2021-03-25 17:34 ` Peter Maydell @ 2021-03-26 1:50 ` Bin Meng 2021-03-26 6:40 ` Howard Spoelstra 0 siblings, 1 reply; 12+ messages in thread From: Bin Meng @ 2021-03-26 1:50 UTC (permalink / raw) To: Peter Maydell; +Cc: Jason Wang, qemu-devel qemu-devel, Howard Spoelstra Hi Howard, On Fri, Mar 26, 2021 at 1:35 AM Peter Maydell <peter.maydell@linaro.org> wrote: > > (adding the relevant people to the cc list) > > On Thu, 25 Mar 2021 at 17:26, Howard Spoelstra <hsp.cat7@gmail.com> wrote: > > > > Hi, > > > > When running qemu-system-ppc with Mac OS guest, the guest crashes when > > using a tap network connection. Openvpn 2.4.9-I601-win10 is installed > > with TAP-Windows 9.24.2. A tap connection called TapQemu is bridged > > with the default ethernet connection. It gets activated when I start > > qemu. > > > > To reproduce, compile qemu-system-ppc from current source and run: > > > > qemu-system-ppc.exe ^ > > -L pc-bios ^ > > -M mac99 ^ > > -m 128 ^ > > -sdl -serial stdio ^ > > -boot c ^ > > -drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^ > > -device sungem,netdev=network01 -netdev tap,ifname=TapQemu,id=network01 > > > > I bisected to the commit below. Thanks for looking into this. Thanks for reporting. Can you please provide some further information: 1. Does "-net user" work on Windows? 2. If running QEMU under Linux, does "-net tap" or "-net user" work? Regards, Bin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest 2021-03-26 1:50 ` Bin Meng @ 2021-03-26 6:40 ` Howard Spoelstra 2021-03-26 6:51 ` Bin Meng ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Howard Spoelstra @ 2021-03-26 6:40 UTC (permalink / raw) To: Bin Meng; +Cc: Peter Maydell, Jason Wang, qemu-devel qemu-devel On Fri, Mar 26, 2021 at 2:50 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > Hi Howard, > > On Fri, Mar 26, 2021 at 1:35 AM Peter Maydell <peter.maydell@linaro.org> wrote: > > > > (adding the relevant people to the cc list) > > > > On Thu, 25 Mar 2021 at 17:26, Howard Spoelstra <hsp.cat7@gmail.com> wrote: > > > > > > Hi, > > > > > > When running qemu-system-ppc with Mac OS guest, the guest crashes when > > > using a tap network connection. Openvpn 2.4.9-I601-win10 is installed > > > with TAP-Windows 9.24.2. A tap connection called TapQemu is bridged > > > with the default ethernet connection. It gets activated when I start > > > qemu. > > > > > > To reproduce, compile qemu-system-ppc from current source and run: > > > > > > qemu-system-ppc.exe ^ > > > -L pc-bios ^ > > > -M mac99 ^ > > > -m 128 ^ > > > -sdl -serial stdio ^ > > > -boot c ^ > > > -drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^ > > > -device sungem,netdev=network01 -netdev tap,ifname=TapQemu,id=network01 > > > > > > I bisected to the commit below. Thanks for looking into this. > > Thanks for reporting. > > Can you please provide some further information: > > 1. Does "-net user" work on Windows? > 2. If running QEMU under Linux, does "-net tap" or "-net user" work? > > Regards, > Bin Hello Bin, Thanks for getting back to me. I forgot to mention that reverting the above patch restores functionality. And that other applications using the same tap device work correctly. In answer to your questions: 1. Yes, slirp works on Windows 10 with this setup. 2. Yes, in Linux both tap and slirp work. My Windows build is done with a fully up to date msys2 installation. I tried to debug in Windows: (gdb) run Starting program: c:\qemu-master-msys2\qemu-system-ppc.exe -L pc-bios -M mac99 -m 128 -sdl -serial stdio -boot c -drive "file=C:\Mac-disks\9.2-usb-pci-ddk.img,format=raw,media=disk" -device "sungem,netdev=network01" -netdev "tap,ifname=TapQemu,id=network01" -S [New Thread 13304.0x1f00] [New Thread 13304.0x2f84] [New Thread 13304.0x3524] [New Thread 13304.0x2b8c] [New Thread 13304.0x368c] [New Thread 13304.0x3668] [New Thread 13304.0xf4c] [New Thread 13304.0x49c] [New Thread 13304.0x1d4c] [New Thread 13304.0x7fc] [Thread 13304.0x7fc exited with code 0] [New Thread 13304.0x357c] [New Thread 13304.0x7c0] [New Thread 13304.0x3564] [New Thread 13304.0x26f4] [New Thread 13304.0x2f68] Program received signal SIGSEGV, Segmentation fault. 0x00007ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll (gdb) bt #0 0x00007ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll #1 0x000800000480bf50 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) Even before I could attach to the process. Best, Howard ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest 2021-03-26 6:40 ` Howard Spoelstra @ 2021-03-26 6:51 ` Bin Meng 2021-03-26 7:58 ` Howard Spoelstra 2021-03-26 8:21 ` BALATON Zoltan 2 siblings, 0 replies; 12+ messages in thread From: Bin Meng @ 2021-03-26 6:51 UTC (permalink / raw) To: Howard Spoelstra; +Cc: Peter Maydell, Jason Wang, qemu-devel qemu-devel Hi Howard, On Fri, Mar 26, 2021 at 2:40 PM Howard Spoelstra <hsp.cat7@gmail.com> wrote: > > On Fri, Mar 26, 2021 at 2:50 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > Hi Howard, > > > > On Fri, Mar 26, 2021 at 1:35 AM Peter Maydell <peter.maydell@linaro.org> wrote: > > > > > > (adding the relevant people to the cc list) > > > > > > On Thu, 25 Mar 2021 at 17:26, Howard Spoelstra <hsp.cat7@gmail.com> wrote: > > > > > > > > Hi, > > > > > > > > When running qemu-system-ppc with Mac OS guest, the guest crashes when > > > > using a tap network connection. Openvpn 2.4.9-I601-win10 is installed > > > > with TAP-Windows 9.24.2. A tap connection called TapQemu is bridged > > > > with the default ethernet connection. It gets activated when I start > > > > qemu. > > > > > > > > To reproduce, compile qemu-system-ppc from current source and run: > > > > > > > > qemu-system-ppc.exe ^ > > > > -L pc-bios ^ > > > > -M mac99 ^ > > > > -m 128 ^ > > > > -sdl -serial stdio ^ > > > > -boot c ^ > > > > -drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^ > > > > -device sungem,netdev=network01 -netdev tap,ifname=TapQemu,id=network01 > > > > > > > > I bisected to the commit below. Thanks for looking into this. > > > > Thanks for reporting. > > > > Can you please provide some further information: > > > > 1. Does "-net user" work on Windows? > > 2. If running QEMU under Linux, does "-net tap" or "-net user" work? > > > > Regards, > > Bin > > Hello Bin, > > Thanks for getting back to me. I forgot to mention that reverting the > above patch restores functionality. And that other applications using > the same tap device work correctly. > In answer to your questions: > > 1. Yes, slirp works on Windows 10 with this setup. > 2. Yes, in Linux both tap and slirp work. Thanks! Just to be clear, the above testing was performed with commit 969e50b61a285b0cc8dea6d4d2ade3f758d5ecc7, right? > > My Windows build is done with a fully up to date msys2 installation. > > I tried to debug in Windows: > (gdb) run > Starting program: c:\qemu-master-msys2\qemu-system-ppc.exe -L pc-bios > -M mac99 -m 128 -sdl -serial stdio -boot c -drive > "file=C:\Mac-disks\9.2-usb-pci-ddk.img,format=raw,media=disk" -device > "sungem,netdev=network01" -netdev "tap,ifname=TapQemu,id=network01" -S > [New Thread 13304.0x1f00] > [New Thread 13304.0x2f84] > [New Thread 13304.0x3524] > [New Thread 13304.0x2b8c] > [New Thread 13304.0x368c] > [New Thread 13304.0x3668] > [New Thread 13304.0xf4c] > [New Thread 13304.0x49c] > [New Thread 13304.0x1d4c] > [New Thread 13304.0x7fc] > [Thread 13304.0x7fc exited with code 0] > [New Thread 13304.0x357c] > [New Thread 13304.0x7c0] > [New Thread 13304.0x3564] > [New Thread 13304.0x26f4] > [New Thread 13304.0x2f68] > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll > (gdb) bt > #0 0x00007ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll > #1 0x000800000480bf50 in ?? () > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > (gdb) > > Even before I could attach to the process. Is QEMU crashed, or the MacOS guest crashed? Regards, Bin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest 2021-03-26 6:40 ` Howard Spoelstra 2021-03-26 6:51 ` Bin Meng @ 2021-03-26 7:58 ` Howard Spoelstra 2021-03-26 8:21 ` BALATON Zoltan 2 siblings, 0 replies; 12+ messages in thread From: Howard Spoelstra @ 2021-03-26 7:58 UTC (permalink / raw) To: Bin Meng; +Cc: Peter Maydell, Jason Wang, qemu-devel qemu-devel Hi Bin, (I forgot to reply to all....) > > In answer to your questions: > > > > 1. Yes, slirp works on Windows 10 with this setup. > > 2. Yes, in Linux both tap and slirp work. > > Thanks! Just to be clear, the above testing was performed with commit > 969e50b61a285b0cc8dea6d4d2ade3f758d5ecc7, right? > Yes, the test is based on current master, so including that commit. As said, reverting it restores tap functionality in Windows. > > > > My Windows build is done with a fully up to date msys2 installation. > > > > I tried to debug in Windows: > > (gdb) run > > Starting program: c:\qemu-master-msys2\qemu-system-ppc.exe -L pc-bios > > -M mac99 -m 128 -sdl -serial stdio -boot c -drive > > "file=C:\Mac-disks\9.2-usb-pci-ddk.img,format=raw,media=disk" -device > > "sungem,netdev=network01" -netdev "tap,ifname=TapQemu,id=network01" -S > > [New Thread 13304.0x1f00] > > [New Thread 13304.0x2f84] > > [New Thread 13304.0x3524] > > [New Thread 13304.0x2b8c] > > [New Thread 13304.0x368c] > > [New Thread 13304.0x3668] > > [New Thread 13304.0xf4c] > > [New Thread 13304.0x49c] > > [New Thread 13304.0x1d4c] > > [New Thread 13304.0x7fc] > > [Thread 13304.0x7fc exited with code 0] > > [New Thread 13304.0x357c] > > [New Thread 13304.0x7c0] > > [New Thread 13304.0x3564] > > [New Thread 13304.0x26f4] > > [New Thread 13304.0x2f68] > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x00007ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll > > (gdb) bt > > #0 0x00007ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll > > #1 0x000800000480bf50 in ?? () > > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > (gdb) > > > > Even before I could attach to the process. > > Is QEMU crashed, or the MacOS guest crashed? Well, that is an interesting question. qemu-system-ppc -M mac99 uses openbios and it crashes while still in the openbios window just when it tries to boot the hd. Besides Mac OS 9.2, I now also tried booting a Mac OS X 10.3 image and it crashes just the same. Tracing the default sungem network device shows: C:\qemu-master-msys2>qemu-system-ppc.exe -L pc-bios -M mac99 -m 128 -sdl -serial stdio -boot c -drive file=C:\Mac-disks\9.2-usb-pci-ddk.img,format=raw,media= disk -device sungem,netdev=network01 -netdev tap,ifname=TapQemu,id=network01 -trace "sung*" sungem_reset Full reset (PCI:1) sungem_rx_reset RX reset sungem_tx_reset TX reset sungem_reset Full reset (PCI:1) sungem_rx_reset RX reset sungem_tx_reset TX reset sungem_rx_mac_disabled Check RX MAC disabled sungem_rx_mac_disabled Check RX MAC disabled sungem_rx_mac_disabled Check RX MAC disabled sungem_mmio_mac_read MMIO mac read from 0x80 val=0x3456 sungem_mmio_mac_read MMIO mac read from 0x84 val=0x12 sungem_mmio_mac_read MMIO mac read from 0x88 val=0x5254 >> ============================================================= >> OpenBIOS 1.1 [Mar 16 2021 08:16] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 1 >> Memory: 128M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,G4 milliseconds isn't unique. Best, Howard ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest 2021-03-26 6:40 ` Howard Spoelstra 2021-03-26 6:51 ` Bin Meng 2021-03-26 7:58 ` Howard Spoelstra @ 2021-03-26 8:21 ` BALATON Zoltan 2021-03-26 8:48 ` Jason Wang 2 siblings, 1 reply; 12+ messages in thread From: BALATON Zoltan @ 2021-03-26 8:21 UTC (permalink / raw) To: Howard Spoelstra Cc: Peter Maydell, Jason Wang, Bin Meng, qemu-devel qemu-devel On Fri, 26 Mar 2021, Howard Spoelstra wrote: > On Fri, Mar 26, 2021 at 2:50 AM Bin Meng <bmeng.cn@gmail.com> wrote: >> >> Hi Howard, >> >> On Fri, Mar 26, 2021 at 1:35 AM Peter Maydell <peter.maydell@linaro.org> wrote: >>> >>> (adding the relevant people to the cc list) >>> >>> On Thu, 25 Mar 2021 at 17:26, Howard Spoelstra <hsp.cat7@gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> When running qemu-system-ppc with Mac OS guest, the guest crashes when >>>> using a tap network connection. Openvpn 2.4.9-I601-win10 is installed >>>> with TAP-Windows 9.24.2. A tap connection called TapQemu is bridged >>>> with the default ethernet connection. It gets activated when I start >>>> qemu. >>>> >>>> To reproduce, compile qemu-system-ppc from current source and run: >>>> >>>> qemu-system-ppc.exe ^ >>>> -L pc-bios ^ >>>> -M mac99 ^ >>>> -m 128 ^ >>>> -sdl -serial stdio ^ >>>> -boot c ^ >>>> -drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^ >>>> -device sungem,netdev=network01 -netdev tap,ifname=TapQemu,id=network01 >>>> >>>> I bisected to the commit below. Thanks for looking into this. >> >> Thanks for reporting. >> >> Can you please provide some further information: >> >> 1. Does "-net user" work on Windows? >> 2. If running QEMU under Linux, does "-net tap" or "-net user" work? >> >> Regards, >> Bin > > Hello Bin, > > Thanks for getting back to me. I forgot to mention that reverting the > above patch restores functionality. And that other applications using > the same tap device work correctly. > In answer to your questions: > > 1. Yes, slirp works on Windows 10 with this setup. > 2. Yes, in Linux both tap and slirp work. > > My Windows build is done with a fully up to date msys2 installation. > > I tried to debug in Windows: > (gdb) run > Starting program: c:\qemu-master-msys2\qemu-system-ppc.exe -L pc-bios > -M mac99 -m 128 -sdl -serial stdio -boot c -drive > "file=C:\Mac-disks\9.2-usb-pci-ddk.img,format=raw,media=disk" -device > "sungem,netdev=network01" -netdev "tap,ifname=TapQemu,id=network01" -S > [New Thread 13304.0x1f00] > [New Thread 13304.0x2f84] > [New Thread 13304.0x3524] > [New Thread 13304.0x2b8c] > [New Thread 13304.0x368c] > [New Thread 13304.0x3668] > [New Thread 13304.0xf4c] > [New Thread 13304.0x49c] > [New Thread 13304.0x1d4c] > [New Thread 13304.0x7fc] > [Thread 13304.0x7fc exited with code 0] > [New Thread 13304.0x357c] > [New Thread 13304.0x7c0] > [New Thread 13304.0x3564] > [New Thread 13304.0x26f4] > [New Thread 13304.0x2f68] > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll > (gdb) bt > #0 0x00007ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll > #1 0x000800000480bf50 in ?? () > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > (gdb) > > Even before I could attach to the process. If you run QEMU under gdb you don't have to attach to it but to get a meaningful backtrace you should configure and compile QEMU with --enable-debug (this will make it run slower so not recommended normally but for debugging that would be needed). If the stack is really corrupted then you may not get a useful backtrace or it may be a problem with gdb on Windows. I've found that gdb on Windows works for simple things but could give bad results for more complex stuff. WinDbg may be better but it's harder to use (needs some registry change I think to enable core dumps then you could open and analyze core dumps with it or it should be able to run command directly but I don't know how that works). Another idea: maybe you could check other threads in gdb. Not sure if that would reveal anything but may worth a try. I think the commands you need are "info threads" and "apply all bt" or something similar. Regards, BALATON Zoltan ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest 2021-03-26 8:21 ` BALATON Zoltan @ 2021-03-26 8:48 ` Jason Wang 2021-03-26 9:00 ` Bin Meng 0 siblings, 1 reply; 12+ messages in thread From: Jason Wang @ 2021-03-26 8:48 UTC (permalink / raw) To: BALATON Zoltan, Howard Spoelstra Cc: Peter Maydell, Bin Meng, qemu-devel qemu-devel [-- Attachment #1: Type: text/plain, Size: 4155 bytes --] 在 2021/3/26 下午4:21, BALATON Zoltan 写道: > On Fri, 26 Mar 2021, Howard Spoelstra wrote: >> On Fri, Mar 26, 2021 at 2:50 AM Bin Meng <bmeng.cn@gmail.com> wrote: >>> >>> Hi Howard, >>> >>> On Fri, Mar 26, 2021 at 1:35 AM Peter Maydell >>> <peter.maydell@linaro.org> wrote: >>>> >>>> (adding the relevant people to the cc list) >>>> >>>> On Thu, 25 Mar 2021 at 17:26, Howard Spoelstra <hsp.cat7@gmail.com> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> When running qemu-system-ppc with Mac OS guest, the guest crashes >>>>> when >>>>> using a tap network connection. Openvpn 2.4.9-I601-win10 is installed >>>>> with TAP-Windows 9.24.2. A tap connection called TapQemu is bridged >>>>> with the default ethernet connection. It gets activated when I start >>>>> qemu. >>>>> >>>>> To reproduce, compile qemu-system-ppc from current source and run: >>>>> >>>>> qemu-system-ppc.exe ^ >>>>> -L pc-bios ^ >>>>> -M mac99 ^ >>>>> -m 128 ^ >>>>> -sdl -serial stdio ^ >>>>> -boot c ^ >>>>> -drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^ >>>>> -device sungem,netdev=network01 -netdev >>>>> tap,ifname=TapQemu,id=network01 >>>>> >>>>> I bisected to the commit below. Thanks for looking into this. >>> >>> Thanks for reporting. >>> >>> Can you please provide some further information: >>> >>> 1. Does "-net user" work on Windows? >>> 2. If running QEMU under Linux, does "-net tap" or "-net user" work? >>> >>> Regards, >>> Bin >> >> Hello Bin, >> >> Thanks for getting back to me. I forgot to mention that reverting the >> above patch restores functionality. And that other applications using >> the same tap device work correctly. >> In answer to your questions: >> >> 1. Yes, slirp works on Windows 10 with this setup. >> 2. Yes, in Linux both tap and slirp work. >> >> My Windows build is done with a fully up to date msys2 installation. >> >> I tried to debug in Windows: >> (gdb) run >> Starting program: c:\qemu-master-msys2\qemu-system-ppc.exe -L pc-bios >> -M mac99 -m 128 -sdl -serial stdio -boot c -drive >> "file=C:\Mac-disks\9.2-usb-pci-ddk.img,format=raw,media=disk" -device >> "sungem,netdev=network01" -netdev "tap,ifname=TapQemu,id=network01" -S >> [New Thread 13304.0x1f00] >> [New Thread 13304.0x2f84] >> [New Thread 13304.0x3524] >> [New Thread 13304.0x2b8c] >> [New Thread 13304.0x368c] >> [New Thread 13304.0x3668] >> [New Thread 13304.0xf4c] >> [New Thread 13304.0x49c] >> [New Thread 13304.0x1d4c] >> [New Thread 13304.0x7fc] >> [Thread 13304.0x7fc exited with code 0] >> [New Thread 13304.0x357c] >> [New Thread 13304.0x7c0] >> [New Thread 13304.0x3564] >> [New Thread 13304.0x26f4] >> [New Thread 13304.0x2f68] >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x00007ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll >> (gdb) bt >> #0 0x00007ffb9edea991 in ?? () from >> c:\qemu-master-msys2\libglib-2.0-0.dll >> #1 0x000800000480bf50 in ?? () >> Backtrace stopped: previous frame inner to this frame (corrupt stack?) >> (gdb) >> >> Even before I could attach to the process. > > If you run QEMU under gdb you don't have to attach to it but to get a > meaningful backtrace you should configure and compile QEMU with > --enable-debug (this will make it run slower so not recommended > normally but for debugging that would be needed). If the stack is > really corrupted then you may not get a useful backtrace or it may be > a problem with gdb on Windows. I've found that gdb on Windows works > for simple things but could give bad results for more complex stuff. > WinDbg may be better but it's harder to use (needs some registry > change I think to enable core dumps then you could open and analyze > core dumps with it or it should be able to run command directly but I > don't know how that works). > > Another idea: maybe you could check other threads in gdb. Not sure if > that would reveal anything but may worth a try. I think the commands > you need are "info threads" and "apply all bt" or something similar. > > Regards, > BALATON Zoltan > It looks to me the patch tires to recycle a temporary buffer to tap thread. Please try to attached fix to see it if works. Thanks [-- Attachment #2: 0001-tap-win32-correctly-recycle-buffers.patch --] [-- Type: text/plain, Size: 1658 bytes --] From bdd7b4b7e13264f30d4abbc6f0f32c8af935ff17 Mon Sep 17 00:00:00 2001 From: Jason Wang <jasowang@redhat.com> Date: Fri, 26 Mar 2021 16:46:43 +0800 Subject: [PATCH] tap-win32: correctly recycle buffers Commit 969e50b61a28 ("net: Pad short frames to minimum size before sending from SLiRP/TAP") tries to pad frames but try to recyle the local array that is used for padding to tap thread. This patch fixes this by recyling the original buffer. Fixes: 969e50b61a28 ("net: Pad short frames to minimum size before sending from SLiRP/TAP") Signed-off-by: Jason Wang <jasowang@redhat.com> --- net/tap-win32.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/tap-win32.c b/net/tap-win32.c index d7c2a8759c..95dacbd171 100644 --- a/net/tap-win32.c +++ b/net/tap-win32.c @@ -686,7 +686,7 @@ static ssize_t tap_receive(NetClientState *nc, const uint8_t *buf, size_t size) static void tap_win32_send(void *opaque) { TAPState *s = opaque; - uint8_t *buf; + uint8_t *buf, orig_buf; int max_size = 4096; int size; uint8_t min_pkt[ETH_ZLEN]; @@ -694,6 +694,8 @@ static void tap_win32_send(void *opaque) size = tap_win32_read(s->handle, &buf, max_size); if (size > 0) { + orig_buf = buf; + if (!s->nc.peer->do_not_pad) { if (eth_pad_short_frame(min_pkt, &min_pktsz, buf, size)) { buf = min_pkt; @@ -702,7 +704,7 @@ static void tap_win32_send(void *opaque) } qemu_send_packet(&s->nc, buf, size); - tap_win32_free_buffer(s->handle, buf); + tap_win32_free_buffer(s->handle, orig_buf); } } -- 2.24.3 (Apple Git-128) ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest 2021-03-26 8:48 ` Jason Wang @ 2021-03-26 9:00 ` Bin Meng 2021-03-26 15:58 ` Howard Spoelstra 0 siblings, 1 reply; 12+ messages in thread From: Bin Meng @ 2021-03-26 9:00 UTC (permalink / raw) To: Jason Wang; +Cc: Peter Maydell, Howard Spoelstra, qemu-devel qemu-devel On Fri, Mar 26, 2021 at 4:49 PM Jason Wang <jasowang@redhat.com> wrote: > > > 在 2021/3/26 下午4:21, BALATON Zoltan 写道: > > On Fri, 26 Mar 2021, Howard Spoelstra wrote: > >> On Fri, Mar 26, 2021 at 2:50 AM Bin Meng <bmeng.cn@gmail.com> wrote: > >>> > >>> Hi Howard, > >>> > >>> On Fri, Mar 26, 2021 at 1:35 AM Peter Maydell > >>> <peter.maydell@linaro.org> wrote: > >>>> > >>>> (adding the relevant people to the cc list) > >>>> > >>>> On Thu, 25 Mar 2021 at 17:26, Howard Spoelstra <hsp.cat7@gmail.com> > >>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> When running qemu-system-ppc with Mac OS guest, the guest crashes > >>>>> when > >>>>> using a tap network connection. Openvpn 2.4.9-I601-win10 is installed > >>>>> with TAP-Windows 9.24.2. A tap connection called TapQemu is bridged > >>>>> with the default ethernet connection. It gets activated when I start > >>>>> qemu. > >>>>> > >>>>> To reproduce, compile qemu-system-ppc from current source and run: > >>>>> > >>>>> qemu-system-ppc.exe ^ > >>>>> -L pc-bios ^ > >>>>> -M mac99 ^ > >>>>> -m 128 ^ > >>>>> -sdl -serial stdio ^ > >>>>> -boot c ^ > >>>>> -drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^ > >>>>> -device sungem,netdev=network01 -netdev > >>>>> tap,ifname=TapQemu,id=network01 > >>>>> > >>>>> I bisected to the commit below. Thanks for looking into this. > >>> > >>> Thanks for reporting. > >>> > >>> Can you please provide some further information: > >>> > >>> 1. Does "-net user" work on Windows? > >>> 2. If running QEMU under Linux, does "-net tap" or "-net user" work? > >>> > >>> Regards, > >>> Bin > >> > >> Hello Bin, > >> > >> Thanks for getting back to me. I forgot to mention that reverting the > >> above patch restores functionality. And that other applications using > >> the same tap device work correctly. > >> In answer to your questions: > >> > >> 1. Yes, slirp works on Windows 10 with this setup. > >> 2. Yes, in Linux both tap and slirp work. > >> > >> My Windows build is done with a fully up to date msys2 installation. > >> > >> I tried to debug in Windows: > >> (gdb) run > >> Starting program: c:\qemu-master-msys2\qemu-system-ppc.exe -L pc-bios > >> -M mac99 -m 128 -sdl -serial stdio -boot c -drive > >> "file=C:\Mac-disks\9.2-usb-pci-ddk.img,format=raw,media=disk" -device > >> "sungem,netdev=network01" -netdev "tap,ifname=TapQemu,id=network01" -S > >> [New Thread 13304.0x1f00] > >> [New Thread 13304.0x2f84] > >> [New Thread 13304.0x3524] > >> [New Thread 13304.0x2b8c] > >> [New Thread 13304.0x368c] > >> [New Thread 13304.0x3668] > >> [New Thread 13304.0xf4c] > >> [New Thread 13304.0x49c] > >> [New Thread 13304.0x1d4c] > >> [New Thread 13304.0x7fc] > >> [Thread 13304.0x7fc exited with code 0] > >> [New Thread 13304.0x357c] > >> [New Thread 13304.0x7c0] > >> [New Thread 13304.0x3564] > >> [New Thread 13304.0x26f4] > >> [New Thread 13304.0x2f68] > >> > >> Program received signal SIGSEGV, Segmentation fault. > >> 0x00007ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll > >> (gdb) bt > >> #0 0x00007ffb9edea991 in ?? () from > >> c:\qemu-master-msys2\libglib-2.0-0.dll > >> #1 0x000800000480bf50 in ?? () > >> Backtrace stopped: previous frame inner to this frame (corrupt stack?) > >> (gdb) > >> > >> Even before I could attach to the process. > > > > If you run QEMU under gdb you don't have to attach to it but to get a > > meaningful backtrace you should configure and compile QEMU with > > --enable-debug (this will make it run slower so not recommended > > normally but for debugging that would be needed). If the stack is > > really corrupted then you may not get a useful backtrace or it may be > > a problem with gdb on Windows. I've found that gdb on Windows works > > for simple things but could give bad results for more complex stuff. > > WinDbg may be better but it's harder to use (needs some registry > > change I think to enable core dumps then you could open and analyze > > core dumps with it or it should be able to run command directly but I > > don't know how that works). > > > > Another idea: maybe you could check other threads in gdb. Not sure if > > that would reveal anything but may worth a try. I think the commands > > you need are "info threads" and "apply all bt" or something similar. > > > > Regards, > > BALATON Zoltan > > > > It looks to me the patch tires to recycle a temporary buffer to tap thread. > > Please try to attached fix to see it if works. Yep, good catch, thanks! This patch looks correct to me. Regards, Bin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest 2021-03-26 9:00 ` Bin Meng @ 2021-03-26 15:58 ` Howard Spoelstra 2021-03-26 19:54 ` BALATON Zoltan 0 siblings, 1 reply; 12+ messages in thread From: Howard Spoelstra @ 2021-03-26 15:58 UTC (permalink / raw) To: Bin Meng; +Cc: Peter Maydell, Jason Wang, qemu-devel qemu-devel On Fri, Mar 26, 2021 at 10:00 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > On Fri, Mar 26, 2021 at 4:49 PM Jason Wang <jasowang@redhat.com> wrote: > > > > > > 在 2021/3/26 下午4:21, BALATON Zoltan 写道: > > > On Fri, 26 Mar 2021, Howard Spoelstra wrote: > > >> On Fri, Mar 26, 2021 at 2:50 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > >>> > > >>> Hi Howard, > > >>> > > >>> On Fri, Mar 26, 2021 at 1:35 AM Peter Maydell > > >>> <peter.maydell@linaro.org> wrote: > > >>>> > > >>>> (adding the relevant people to the cc list) > > >>>> > > >>>> On Thu, 25 Mar 2021 at 17:26, Howard Spoelstra <hsp.cat7@gmail.com> > > >>>> wrote: > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> When running qemu-system-ppc with Mac OS guest, the guest crashes > > >>>>> when > > >>>>> using a tap network connection. Openvpn 2.4.9-I601-win10 is installed > > >>>>> with TAP-Windows 9.24.2. A tap connection called TapQemu is bridged > > >>>>> with the default ethernet connection. It gets activated when I start > > >>>>> qemu. > > >>>>> > > >>>>> To reproduce, compile qemu-system-ppc from current source and run: > > >>>>> > > >>>>> qemu-system-ppc.exe ^ > > >>>>> -L pc-bios ^ > > >>>>> -M mac99 ^ > > >>>>> -m 128 ^ > > >>>>> -sdl -serial stdio ^ > > >>>>> -boot c ^ > > >>>>> -drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^ > > >>>>> -device sungem,netdev=network01 -netdev > > >>>>> tap,ifname=TapQemu,id=network01 > > >>>>> > > >>>>> I bisected to the commit below. Thanks for looking into this. > > >>> > > >>> Thanks for reporting. > > >>> > > >>> Can you please provide some further information: > > >>> > > >>> 1. Does "-net user" work on Windows? > > >>> 2. If running QEMU under Linux, does "-net tap" or "-net user" work? > > >>> > > >>> Regards, > > >>> Bin > > >> > > >> Hello Bin, > > >> > > >> Thanks for getting back to me. I forgot to mention that reverting the > > >> above patch restores functionality. And that other applications using > > >> the same tap device work correctly. > > >> In answer to your questions: > > >> > > >> 1. Yes, slirp works on Windows 10 with this setup. > > >> 2. Yes, in Linux both tap and slirp work. > > >> > > >> My Windows build is done with a fully up to date msys2 installation. > > >> > > >> I tried to debug in Windows: > > >> (gdb) run > > >> Starting program: c:\qemu-master-msys2\qemu-system-ppc.exe -L pc-bios > > >> -M mac99 -m 128 -sdl -serial stdio -boot c -drive > > >> "file=C:\Mac-disks\9.2-usb-pci-ddk.img,format=raw,media=disk" -device > > >> "sungem,netdev=network01" -netdev "tap,ifname=TapQemu,id=network01" -S > > >> [New Thread 13304.0x1f00] > > >> [New Thread 13304.0x2f84] > > >> [New Thread 13304.0x3524] > > >> [New Thread 13304.0x2b8c] > > >> [New Thread 13304.0x368c] > > >> [New Thread 13304.0x3668] > > >> [New Thread 13304.0xf4c] > > >> [New Thread 13304.0x49c] > > >> [New Thread 13304.0x1d4c] > > >> [New Thread 13304.0x7fc] > > >> [Thread 13304.0x7fc exited with code 0] > > >> [New Thread 13304.0x357c] > > >> [New Thread 13304.0x7c0] > > >> [New Thread 13304.0x3564] > > >> [New Thread 13304.0x26f4] > > >> [New Thread 13304.0x2f68] > > >> > > >> Program received signal SIGSEGV, Segmentation fault. > > >> 0x00007ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll > > >> (gdb) bt > > >> #0 0x00007ffb9edea991 in ?? () from > > >> c:\qemu-master-msys2\libglib-2.0-0.dll > > >> #1 0x000800000480bf50 in ?? () > > >> Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > >> (gdb) > > >> > > >> Even before I could attach to the process. > > > > > > If you run QEMU under gdb you don't have to attach to it but to get a > > > meaningful backtrace you should configure and compile QEMU with > > > --enable-debug (this will make it run slower so not recommended > > > normally but for debugging that would be needed). If the stack is > > > really corrupted then you may not get a useful backtrace or it may be > > > a problem with gdb on Windows. I've found that gdb on Windows works > > > for simple things but could give bad results for more complex stuff. > > > WinDbg may be better but it's harder to use (needs some registry > > > change I think to enable core dumps then you could open and analyze > > > core dumps with it or it should be able to run command directly but I > > > don't know how that works). > > > > > > Another idea: maybe you could check other threads in gdb. Not sure if > > > that would reveal anything but may worth a try. I think the commands > > > you need are "info threads" and "apply all bt" or something similar. > > > > > > Regards, > > > BALATON Zoltan > > > > > > > It looks to me the patch tires to recycle a temporary buffer to tap thread. > > > > Please try to attached fix to see it if works. > > Yep, good catch, thanks! This patch looks correct to me. > > Regards, > Bin Hi, While the patch applies, it will not compile: ../net/tap-win32.c: In function 'tap_win32_send': ../net/tap-win32.c:697:18: error: assignment to 'uint8_t' {aka 'unsigned char'} from 'uint8_t *' {aka 'unsigned char *'} makes integer from pointer without a cast [-Werror=int-conversion] 697 | orig_buf = buf; | ^ ../net/tap-win32.c:707:42: error: passing argument 2 of 'tap_win32_free_buffer' makes pointer from integer without a cast [-Werror=int-conversion] 707 | tap_win32_free_buffer(s->handle, orig_buf); | ^~~~~~~~ | | | uint8_t {aka unsigned char} ../net/tap-win32.c:590:44: note: expected 'uint8_t *' {aka 'unsigned char *'} but argument is of type 'uint8_t' {aka 'unsigned char'} 590 | uint8_t *pbuf) | ~~~~~~~~~^~~~ Best, Howard ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest 2021-03-26 15:58 ` Howard Spoelstra @ 2021-03-26 19:54 ` BALATON Zoltan 2021-03-27 5:13 ` Howard Spoelstra 0 siblings, 1 reply; 12+ messages in thread From: BALATON Zoltan @ 2021-03-26 19:54 UTC (permalink / raw) To: Howard Spoelstra Cc: Peter Maydell, Jason Wang, Bin Meng, qemu-devel qemu-devel [-- Attachment #1: Type: text/plain, Size: 5919 bytes --] On Fri, 26 Mar 2021, Howard Spoelstra wrote: > On Fri, Mar 26, 2021 at 10:00 AM Bin Meng <bmeng.cn@gmail.com> wrote: >> >> On Fri, Mar 26, 2021 at 4:49 PM Jason Wang <jasowang@redhat.com> wrote: >>> >>> >>> 在 2021/3/26 下午4:21, BALATON Zoltan 写道: >>>> On Fri, 26 Mar 2021, Howard Spoelstra wrote: >>>>> On Fri, Mar 26, 2021 at 2:50 AM Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>> >>>>>> Hi Howard, >>>>>> >>>>>> On Fri, Mar 26, 2021 at 1:35 AM Peter Maydell >>>>>> <peter.maydell@linaro.org> wrote: >>>>>>> >>>>>>> (adding the relevant people to the cc list) >>>>>>> >>>>>>> On Thu, 25 Mar 2021 at 17:26, Howard Spoelstra <hsp.cat7@gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> When running qemu-system-ppc with Mac OS guest, the guest crashes >>>>>>>> when >>>>>>>> using a tap network connection. Openvpn 2.4.9-I601-win10 is installed >>>>>>>> with TAP-Windows 9.24.2. A tap connection called TapQemu is bridged >>>>>>>> with the default ethernet connection. It gets activated when I start >>>>>>>> qemu. >>>>>>>> >>>>>>>> To reproduce, compile qemu-system-ppc from current source and run: >>>>>>>> >>>>>>>> qemu-system-ppc.exe ^ >>>>>>>> -L pc-bios ^ >>>>>>>> -M mac99 ^ >>>>>>>> -m 128 ^ >>>>>>>> -sdl -serial stdio ^ >>>>>>>> -boot c ^ >>>>>>>> -drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^ >>>>>>>> -device sungem,netdev=network01 -netdev >>>>>>>> tap,ifname=TapQemu,id=network01 >>>>>>>> >>>>>>>> I bisected to the commit below. Thanks for looking into this. >>>>>> >>>>>> Thanks for reporting. >>>>>> >>>>>> Can you please provide some further information: >>>>>> >>>>>> 1. Does "-net user" work on Windows? >>>>>> 2. If running QEMU under Linux, does "-net tap" or "-net user" work? >>>>>> >>>>>> Regards, >>>>>> Bin >>>>> >>>>> Hello Bin, >>>>> >>>>> Thanks for getting back to me. I forgot to mention that reverting the >>>>> above patch restores functionality. And that other applications using >>>>> the same tap device work correctly. >>>>> In answer to your questions: >>>>> >>>>> 1. Yes, slirp works on Windows 10 with this setup. >>>>> 2. Yes, in Linux both tap and slirp work. >>>>> >>>>> My Windows build is done with a fully up to date msys2 installation. >>>>> >>>>> I tried to debug in Windows: >>>>> (gdb) run >>>>> Starting program: c:\qemu-master-msys2\qemu-system-ppc.exe -L pc-bios >>>>> -M mac99 -m 128 -sdl -serial stdio -boot c -drive >>>>> "file=C:\Mac-disks\9.2-usb-pci-ddk.img,format=raw,media=disk" -device >>>>> "sungem,netdev=network01" -netdev "tap,ifname=TapQemu,id=network01" -S >>>>> [New Thread 13304.0x1f00] >>>>> [New Thread 13304.0x2f84] >>>>> [New Thread 13304.0x3524] >>>>> [New Thread 13304.0x2b8c] >>>>> [New Thread 13304.0x368c] >>>>> [New Thread 13304.0x3668] >>>>> [New Thread 13304.0xf4c] >>>>> [New Thread 13304.0x49c] >>>>> [New Thread 13304.0x1d4c] >>>>> [New Thread 13304.0x7fc] >>>>> [Thread 13304.0x7fc exited with code 0] >>>>> [New Thread 13304.0x357c] >>>>> [New Thread 13304.0x7c0] >>>>> [New Thread 13304.0x3564] >>>>> [New Thread 13304.0x26f4] >>>>> [New Thread 13304.0x2f68] >>>>> >>>>> Program received signal SIGSEGV, Segmentation fault. >>>>> 0x00007ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll >>>>> (gdb) bt >>>>> #0 0x00007ffb9edea991 in ?? () from >>>>> c:\qemu-master-msys2\libglib-2.0-0.dll >>>>> #1 0x000800000480bf50 in ?? () >>>>> Backtrace stopped: previous frame inner to this frame (corrupt stack?) >>>>> (gdb) >>>>> >>>>> Even before I could attach to the process. >>>> >>>> If you run QEMU under gdb you don't have to attach to it but to get a >>>> meaningful backtrace you should configure and compile QEMU with >>>> --enable-debug (this will make it run slower so not recommended >>>> normally but for debugging that would be needed). If the stack is >>>> really corrupted then you may not get a useful backtrace or it may be >>>> a problem with gdb on Windows. I've found that gdb on Windows works >>>> for simple things but could give bad results for more complex stuff. >>>> WinDbg may be better but it's harder to use (needs some registry >>>> change I think to enable core dumps then you could open and analyze >>>> core dumps with it or it should be able to run command directly but I >>>> don't know how that works). >>>> >>>> Another idea: maybe you could check other threads in gdb. Not sure if >>>> that would reveal anything but may worth a try. I think the commands >>>> you need are "info threads" and "apply all bt" or something similar. >>>> >>>> Regards, >>>> BALATON Zoltan >>>> >>> >>> It looks to me the patch tires to recycle a temporary buffer to tap thread. >>> >>> Please try to attached fix to see it if works. >> >> Yep, good catch, thanks! This patch looks correct to me. >> >> Regards, >> Bin > > Hi, > > While the patch applies, it will not compile: > > ../net/tap-win32.c: In function 'tap_win32_send': > ../net/tap-win32.c:697:18: error: assignment to 'uint8_t' {aka > 'unsigned char'} from 'uint8_t *' {aka 'unsigned char *'} makes > integer from pointer without a cast [-Werror=int-conversion] > 697 | orig_buf = buf; > | ^ > ../net/tap-win32.c:707:42: error: passing argument 2 of > 'tap_win32_free_buffer' makes pointer from integer without a cast > [-Werror=int-conversion] > 707 | tap_win32_free_buffer(s->handle, orig_buf); > | ^~~~~~~~ > | | > | uint8_t {aka unsigned char} > ../net/tap-win32.c:590:44: note: expected 'uint8_t *' {aka 'unsigned > char *'} but argument is of type 'uint8_t' {aka 'unsigned char'} > 590 | uint8_t *pbuf) > | ~~~~~~~~~^~~~ Patch missing a * from this line: + uint8_t *buf, orig_buf; should be + uint8_t *buf, *orig_buf; Regards, BALATON Zoltan ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest 2021-03-26 19:54 ` BALATON Zoltan @ 2021-03-27 5:13 ` Howard Spoelstra 0 siblings, 0 replies; 12+ messages in thread From: Howard Spoelstra @ 2021-03-27 5:13 UTC (permalink / raw) To: BALATON Zoltan; +Cc: Peter Maydell, Jason Wang, Bin Meng, qemu-devel qemu-devel On Fri, Mar 26, 2021 at 8:54 PM BALATON Zoltan <balaton@eik.bme.hu> wrote: > > On Fri, 26 Mar 2021, Howard Spoelstra wrote: > > On Fri, Mar 26, 2021 at 10:00 AM Bin Meng <bmeng.cn@gmail.com> wrote: > >> > >> On Fri, Mar 26, 2021 at 4:49 PM Jason Wang <jasowang@redhat.com> wrote: > >>> > >>> > >>> 在 2021/3/26 下午4:21, BALATON Zoltan 写道: > >>>> On Fri, 26 Mar 2021, Howard Spoelstra wrote: > >>>>> On Fri, Mar 26, 2021 at 2:50 AM Bin Meng <bmeng.cn@gmail.com> wrote: > >>>>>> > >>>>>> Hi Howard, > >>>>>> > >>>>>> On Fri, Mar 26, 2021 at 1:35 AM Peter Maydell > >>>>>> <peter.maydell@linaro.org> wrote: > >>>>>>> > >>>>>>> (adding the relevant people to the cc list) > >>>>>>> > >>>>>>> On Thu, 25 Mar 2021 at 17:26, Howard Spoelstra <hsp.cat7@gmail.com> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> When running qemu-system-ppc with Mac OS guest, the guest crashes > >>>>>>>> when > >>>>>>>> using a tap network connection. Openvpn 2.4.9-I601-win10 is installed > >>>>>>>> with TAP-Windows 9.24.2. A tap connection called TapQemu is bridged > >>>>>>>> with the default ethernet connection. It gets activated when I start > >>>>>>>> qemu. > >>>>>>>> > >>>>>>>> To reproduce, compile qemu-system-ppc from current source and run: > >>>>>>>> > >>>>>>>> qemu-system-ppc.exe ^ > >>>>>>>> -L pc-bios ^ > >>>>>>>> -M mac99 ^ > >>>>>>>> -m 128 ^ > >>>>>>>> -sdl -serial stdio ^ > >>>>>>>> -boot c ^ > >>>>>>>> -drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^ > >>>>>>>> -device sungem,netdev=network01 -netdev > >>>>>>>> tap,ifname=TapQemu,id=network01 > >>>>>>>> > >>>>>>>> I bisected to the commit below. Thanks for looking into this. > >>>>>> > >>>>>> Thanks for reporting. > >>>>>> > >>>>>> Can you please provide some further information: > >>>>>> > >>>>>> 1. Does "-net user" work on Windows? > >>>>>> 2. If running QEMU under Linux, does "-net tap" or "-net user" work? > >>>>>> > >>>>>> Regards, > >>>>>> Bin > >>>>> > >>>>> Hello Bin, > >>>>> > >>>>> Thanks for getting back to me. I forgot to mention that reverting the > >>>>> above patch restores functionality. And that other applications using > >>>>> the same tap device work correctly. > >>>>> In answer to your questions: > >>>>> > >>>>> 1. Yes, slirp works on Windows 10 with this setup. > >>>>> 2. Yes, in Linux both tap and slirp work. > >>>>> > >>>>> My Windows build is done with a fully up to date msys2 installation. > >>>>> > >>>>> I tried to debug in Windows: > >>>>> (gdb) run > >>>>> Starting program: c:\qemu-master-msys2\qemu-system-ppc.exe -L pc-bios > >>>>> -M mac99 -m 128 -sdl -serial stdio -boot c -drive > >>>>> "file=C:\Mac-disks\9.2-usb-pci-ddk.img,format=raw,media=disk" -device > >>>>> "sungem,netdev=network01" -netdev "tap,ifname=TapQemu,id=network01" -S > >>>>> [New Thread 13304.0x1f00] > >>>>> [New Thread 13304.0x2f84] > >>>>> [New Thread 13304.0x3524] > >>>>> [New Thread 13304.0x2b8c] > >>>>> [New Thread 13304.0x368c] > >>>>> [New Thread 13304.0x3668] > >>>>> [New Thread 13304.0xf4c] > >>>>> [New Thread 13304.0x49c] > >>>>> [New Thread 13304.0x1d4c] > >>>>> [New Thread 13304.0x7fc] > >>>>> [Thread 13304.0x7fc exited with code 0] > >>>>> [New Thread 13304.0x357c] > >>>>> [New Thread 13304.0x7c0] > >>>>> [New Thread 13304.0x3564] > >>>>> [New Thread 13304.0x26f4] > >>>>> [New Thread 13304.0x2f68] > >>>>> > >>>>> Program received signal SIGSEGV, Segmentation fault. > >>>>> 0x00007ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll > >>>>> (gdb) bt > >>>>> #0 0x00007ffb9edea991 in ?? () from > >>>>> c:\qemu-master-msys2\libglib-2.0-0.dll > >>>>> #1 0x000800000480bf50 in ?? () > >>>>> Backtrace stopped: previous frame inner to this frame (corrupt stack?) > >>>>> (gdb) > >>>>> > >>>>> Even before I could attach to the process. > >>>> > >>>> If you run QEMU under gdb you don't have to attach to it but to get a > >>>> meaningful backtrace you should configure and compile QEMU with > >>>> --enable-debug (this will make it run slower so not recommended > >>>> normally but for debugging that would be needed). If the stack is > >>>> really corrupted then you may not get a useful backtrace or it may be > >>>> a problem with gdb on Windows. I've found that gdb on Windows works > >>>> for simple things but could give bad results for more complex stuff. > >>>> WinDbg may be better but it's harder to use (needs some registry > >>>> change I think to enable core dumps then you could open and analyze > >>>> core dumps with it or it should be able to run command directly but I > >>>> don't know how that works). > >>>> > >>>> Another idea: maybe you could check other threads in gdb. Not sure if > >>>> that would reveal anything but may worth a try. I think the commands > >>>> you need are "info threads" and "apply all bt" or something similar. > >>>> > >>>> Regards, > >>>> BALATON Zoltan > >>>> > >>> > >>> It looks to me the patch tires to recycle a temporary buffer to tap thread. > >>> > >>> Please try to attached fix to see it if works. > >> > >> Yep, good catch, thanks! This patch looks correct to me. > >> > >> Regards, > >> Bin > > > > Hi, > > > > While the patch applies, it will not compile: > > > > ../net/tap-win32.c: In function 'tap_win32_send': > > ../net/tap-win32.c:697:18: error: assignment to 'uint8_t' {aka > > 'unsigned char'} from 'uint8_t *' {aka 'unsigned char *'} makes > > integer from pointer without a cast [-Werror=int-conversion] > > 697 | orig_buf = buf; > > | ^ > > ../net/tap-win32.c:707:42: error: passing argument 2 of > > 'tap_win32_free_buffer' makes pointer from integer without a cast > > [-Werror=int-conversion] > > 707 | tap_win32_free_buffer(s->handle, orig_buf); > > | ^~~~~~~~ > > | | > > | uint8_t {aka unsigned char} > > ../net/tap-win32.c:590:44: note: expected 'uint8_t *' {aka 'unsigned > > char *'} but argument is of type 'uint8_t' {aka 'unsigned char'} > > 590 | uint8_t *pbuf) > > | ~~~~~~~~~^~~~ > > Patch missing a * from this line: > > + uint8_t *buf, orig_buf; > > should be > > + uint8_t *buf, *orig_buf; > > Regards, > BALATON Zoltan Hi all, Together with that * from Zoltan, this patch restores tap networking in Windows. Thanks! So: Tested-by: Howard Spoelstra <hsp.cat7@gmail.com> ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-03-27 5:15 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-25 17:19 Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest Howard Spoelstra 2021-03-25 17:34 ` Peter Maydell 2021-03-26 1:50 ` Bin Meng 2021-03-26 6:40 ` Howard Spoelstra 2021-03-26 6:51 ` Bin Meng 2021-03-26 7:58 ` Howard Spoelstra 2021-03-26 8:21 ` BALATON Zoltan 2021-03-26 8:48 ` Jason Wang 2021-03-26 9:00 ` Bin Meng 2021-03-26 15:58 ` Howard Spoelstra 2021-03-26 19:54 ` BALATON Zoltan 2021-03-27 5:13 ` Howard Spoelstra
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).