[Qemu-devel] [Bug 732155] Re: system_reset doesn't work with qemu-kvm and latest SeaBIOS
Hi Thomas, thanks for the triage. I'm a few years past working on this project directly so if it's not affecting anyone else I'd probably just close this bug. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/732155 Title: system_reset doesn't work with qemu-kvm and latest SeaBIOS Status in QEMU: Incomplete Bug description: I've built qemu-kvm and seabios from the latest git sources, and found that the system_reset monitor command causes a freeze if I start qemu- system-x86_64 with the -no-kvm flag. This is a serial log from an attempt at rebooting: $ ./x86_64-softmmu/qemu-system-x86_64 -monitor stdio -bios ../seabios/out/bios.bin -serial /dev/stdout -no-kvm QEMU 0.14.50 monitor - type 'help' for more information (qemu) Changing serial settings was 0/0 now 3/0 Start bios (version pre-0.6.3-20110309_171929-desk4) Ram Size=0x0800 (0x high) CPU Mhz=2202 PCI: pci_bios_init_bus_rec bus = 0x0 PIIX3/PIIX4 init: elcr=00 0c PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 region 4: 0xc000 PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8 region 0: 0xf000 region 1: 0xf200 region 6: 0xf201 PCI: bus=0 devfn=0x18: vendor_id=0x10ec device_id=0x8139 region 0: 0xc100 region 1: 0xf202 region 6: 0xf203 Found 1 cpu(s) max supported 1 cpu(s) MP table addr=0x000fdb40 MPC table addr=0x000fdb50 size=224 SMBIOS ptr=0x000fdb20 table=0x07fffef0 ACPI tables: RSDP=0x000fdaf0 RSDT=0x07ffd6a0 Scan for VGA option rom Running option rom at c000:0003 Turning on vga text mode console SeaBIOS (version pre-0.6.3-20110309_171929-desk4) PS2 keyboard initialized Found 1 lpt ports Found 1 serial ports ATA controller 0 at 1f0/3f4/0 (irq 14 dev 9) ATA controller 1 at 170/374/0 (irq 15 dev 9) DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD] Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0 Scan for option roms Running option rom at c900:0003 pnp call arg1=60 pmm call arg1=0 pmm call arg1=2 pmm call arg1=0 Searching bootorder for: /pci@i0cf8/*@3 Searching bootorder for: /rom@genroms/vapic.bin Running option rom at c980:0003 ebda moved from 9fc00 to 9f400 Returned 53248 bytes of ZoneHigh e820 map has 6 items: 0: - 0009f400 = 1 1: 0009f400 - 000a = 2 2: 000f - 0010 = 2 3: 0010 - 07ffd000 = 1 4: 07ffd000 - 0800 = 2 5: fffc - 0001 = 2 enter handle_19: NULL Booting from DVD/CD... Device reports MEDIUM NOT PRESENT atapi_is_ready returned -1 Boot failed: Could not read from CDROM (code 0003) enter handle_18: NULL Booting from ROM... Booting from c900:0336 (qemu) (qemu) system_reset (qemu) RESET REQUESTEDChanging serial settings was 0/0 now 3/0 Start bios (version pre-0.6.3-20110309_171929-desk4) Attempting a hard reboot prep_reset apm_shutdown? i8042_reboot i8042: wait to write... i8042: outb RESET REQUESTED (qemu) (qemu) (qemu) (qemu) info cpus * CPU #0: pc=0xfff0 thread_id=18125 (qemu) system_reset (qemu) RESET REQUESTED (qemu) (qemu) q I've tried fiddling a few build options in SeaBIOS but I'm not sure that's where the issue lies. The RESET REQUESTED is me adding some extra debug to vl.c:1477 in the clause that tests for a reset request, and the i8042: lines are debug lines from seabios tracing the execution of the reset request. This may be a bug in SeaBIOS of course, since I can replicate the behaviour on my distro's qemu and kvm packages. However it seems odd that qemu behaves differently with KVM turned on (i.e. system_reset works) than with it disabled. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/732155/+subscriptions
[Qemu-devel] [Bug 778032] [NEW] qemu spinning on serial port writes
Public bug reported: As originally found at http://www.mail- archive.com/k...@vger.kernel.org/msg08745.html from 3 years ago! Basically qemu seizes up in the event that the file descriptor for its emulated serial port has a full buffer, i.e. write() returns EAGAIN. For me, this happened when the serial port was being directed through a UNIX socket, with a default-sized 4KB buffer. Just the normal output from a Linux kernel boot caused it to seize up, and stop the main emulation / select loop. My suggestion is to remove the detection of EAGAIN in qemu-char.c:521, so that if the buffer is full, KVM discards the byte(s) it was trying to write. This is a surely better outcome than the process spinning forever. I will submit a separate patch to control the buffer sizes when creating UNIX sockets, which will help allow slow-reading processes to tune things so that they don't miss any output. Additionally, in the context of a hosted environment, if the -serial option is used, this could be a small security issue. An untrusted user of a guest system, knowing their serial output is going via a small buffer, could spew output to their /dev/ttyS0 at a rate fast enough to trigger this bug and eat a CPU core on the host. To quote David S. Ahern's original bug report (mine was the same, only with the latest version from git, so line numbers may have changed - my suggested fix above is accurate though): I am trying to redirect a guest's boot output through the host's serial port. Shortly after launching qemu, the main thread is spinning on: write(9, 0, 1) = -1 EAGAIN (Resource temporarily unavailable) fd 9 is the serial port, ttyS0. The backtrace for the thread is: #0 0x2ac3433f8c0b in write () from /lib64/libpthread.so.0 #1 0x00475df9 in send_all (fd=9, buf=value optimized out, len1=1) at qemu-char.c:477 #2 0x0043a102 in serial_xmit (opaque=value optimized out) at /root/kvm-81/qemu/hw/serial.c:311 #3 0x0043a591 in serial_ioport_write (opaque=0x14971790, addr=value optimized out, val=48) at /root/kvm-81/qemu/hw/serial.c:366 #4 0x410eeedc in ?? () #5 0x00129000 in ?? () #6 0x14821fa0 in ?? () #7 0x0007 in ?? () #8 0x004a54c5 in tlb_set_page_exec (env=0x10ab4, vaddr=46912496956816, paddr=1, prot=-1, mmu_idx=0, is_softmmu=1) at /root/kvm-81/qemu/exec.c:388 #9 0x00512f3b in tlb_fill (addr=345446292, is_write=1, mmu_idx=-1, retaddr=0x0) at /root/kvm-81/qemu/target-i386/op_helper.c:4690 #10 0x004a6bd2 in __ldb_cmmu (addr=9, mmu_idx=0) at /root/kvm-81/qemu/softmmu_template.h:135 #11 0x004a879b in cpu_x86_exec (env1=value optimized out) at /root/kvm-81/qemu/cpu-exec.c:628 #12 0x0040ba29 in main (argc=12, argv=0x7fff67f7a398) at /root/kvm-81/qemu/vl.c:3816 send_all() invokes unix_write() which by design is not breaking out on EAGAIN. The following command is enough to show the problem: qemu-system-x86_64 -m 256 -smp 1 -no-kvm \ -drivefile=/dev/cciss/c0d0,if=scsi,cache=off,boot=on \ -vnc :1 -serial /dev/ttyS0 The guest is running RHEL3 with the parameter 'console=ttyS0' added to grub.conf; the problem appears to be with qemu, so I would expect it to show with any linux guest. This particular host is running RHEL5.2 with kvm-81, but I have also seen the problem with Fedora-9 as the host OS. Yes, the serial port of the server is connected to another system via a null modem. If I change the serial argument to '-serial udp::4555' and use 'nc -u -l localhost 4555 /dev/ttyS0' I see the guest's boot output show up on the second system as expected. I'd prefer to be able to use the serial port connection directly without nc as a proxy. Suggestions? ** Affects: qemu Importance: Undecided Status: New ** Tags: eagain serial -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/778032 Title: qemu spinning on serial port writes Status in QEMU: New Bug description: As originally found at http://www.mail- archive.com/k...@vger.kernel.org/msg08745.html from 3 years ago! Basically qemu seizes up in the event that the file descriptor for its emulated serial port has a full buffer, i.e. write() returns EAGAIN. For me, this happened when the serial port was being directed through a UNIX socket, with a default-sized 4KB buffer. Just the normal output from a Linux kernel boot caused it to seize up, and stop the main emulation / select loop. My suggestion is to remove the detection of EAGAIN in qemu-char.c:521, so that if the buffer is full, KVM discards the byte(s) it was trying to write. This is a surely better outcome than the process spinning forever. I will submit a separate patch to control the buffer sizes when creating UNIX sockets, which will help allow slow-reading processes to tune things so that they don't miss any output.
[Qemu-devel] [Bug 732155] Re: system_reset doesn't work with qemu-kvm and latest SeaBIOS
This patch to SeaBIOS seems to fix it, but I still think there's a bug in kvm if it behaves differently with or without the -no-kvm flag. ** Tags added: bios kvm reset ** Patch added: qemu-reset.patch https://bugs.launchpad.net/qemu/+bug/732155/+attachment/1906859/+files/qemu-reset.patch -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/732155 Title: system_reset doesn't work with qemu-kvm and latest SeaBIOS Status in QEMU: New Bug description: I've built qemu-kvm and seabios from the latest git sources, and found that the system_reset monitor command causes a freeze if I start qemu- system-x86_64 with the -no-kvm flag. This is a serial log from an attempt at rebooting: $ ./x86_64-softmmu/qemu-system-x86_64 -monitor stdio -bios ../seabios/out/bios.bin -serial /dev/stdout -no-kvm QEMU 0.14.50 monitor - type 'help' for more information (qemu) Changing serial settings was 0/0 now 3/0 Start bios (version pre-0.6.3-20110309_171929-desk4) Ram Size=0x0800 (0x high) CPU Mhz=2202 PCI: pci_bios_init_bus_rec bus = 0x0 PIIX3/PIIX4 init: elcr=00 0c PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 region 4: 0xc000 PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8 region 0: 0xf000 region 1: 0xf200 region 6: 0xf201 PCI: bus=0 devfn=0x18: vendor_id=0x10ec device_id=0x8139 region 0: 0xc100 region 1: 0xf202 region 6: 0xf203 Found 1 cpu(s) max supported 1 cpu(s) MP table addr=0x000fdb40 MPC table addr=0x000fdb50 size=224 SMBIOS ptr=0x000fdb20 table=0x07fffef0 ACPI tables: RSDP=0x000fdaf0 RSDT=0x07ffd6a0 Scan for VGA option rom Running option rom at c000:0003 Turning on vga text mode console SeaBIOS (version pre-0.6.3-20110309_171929-desk4) PS2 keyboard initialized Found 1 lpt ports Found 1 serial ports ATA controller 0 at 1f0/3f4/0 (irq 14 dev 9) ATA controller 1 at 170/374/0 (irq 15 dev 9) DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD] Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0 Scan for option roms Running option rom at c900:0003 pnp call arg1=60 pmm call arg1=0 pmm call arg1=2 pmm call arg1=0 Searching bootorder for: /pci@i0cf8/*@3 Searching bootorder for: /rom@genroms/vapic.bin Running option rom at c980:0003 ebda moved from 9fc00 to 9f400 Returned 53248 bytes of ZoneHigh e820 map has 6 items: 0: - 0009f400 = 1 1: 0009f400 - 000a = 2 2: 000f - 0010 = 2 3: 0010 - 07ffd000 = 1 4: 07ffd000 - 0800 = 2 5: fffc - 0001 = 2 enter handle_19: NULL Booting from DVD/CD... Device reports MEDIUM NOT PRESENT atapi_is_ready returned -1 Boot failed: Could not read from CDROM (code 0003) enter handle_18: NULL Booting from ROM... Booting from c900:0336 (qemu) (qemu) system_reset (qemu) RESET REQUESTEDChanging serial settings was 0/0 now 3/0 Start bios (version pre-0.6.3-20110309_171929-desk4) Attempting a hard reboot prep_reset apm_shutdown? i8042_reboot i8042: wait to write... i8042: outb RESET REQUESTED (qemu) (qemu) (qemu) (qemu) info cpus * CPU #0: pc=0xfff0 thread_id=18125 (qemu) system_reset (qemu) RESET REQUESTED (qemu) (qemu) q I've tried fiddling a few build options in SeaBIOS but I'm not sure that's where the issue lies. The RESET REQUESTED is me adding some extra debug to vl.c:1477 in the clause that tests for a reset request, and the i8042: lines are debug lines from seabios tracing the execution of the reset request. This may be a bug in SeaBIOS of course, since I can replicate the behaviour on my distro's qemu and kvm packages. However it seems odd that qemu behaves differently with KVM turned on (i.e. system_reset works) than with it disabled.
[Qemu-devel] [Bug 714629] [NEW] BIOS doesn't load when read() returns less than the full ROM length
Public bug reported: When qemu is running over a 9p filesystem (e.g. when running underneath -virtfs of another qemu), and probably some other network filesystems, it fails to read its BIOS image. This is because it uses a single low- level read() call on the bios.bin, asking for the full file. However read() may return less than the full length, and it's the caller's responsibility to call it repeatedly if necessary. When read does come up short, qemu doesn't repeat the call, and reports an error instead. The attached patch fixes the one problem I saw, but I haven't tried to cover the general case (e.g. extension ROMs). ** Affects: qemu Importance: Undecided Status: New ** Tags: bios -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/714629 Title: BIOS doesn't load when read() returns less than the full ROM length Status in QEMU: New Bug description: When qemu is running over a 9p filesystem (e.g. when running underneath -virtfs of another qemu), and probably some other network filesystems, it fails to read its BIOS image. This is because it uses a single low-level read() call on the bios.bin, asking for the full file. However read() may return less than the full length, and it's the caller's responsibility to call it repeatedly if necessary. When read does come up short, qemu doesn't repeat the call, and reports an error instead. The attached patch fixes the one problem I saw, but I haven't tried to cover the general case (e.g. extension ROMs).
[Qemu-devel] [Bug 714629] Re: BIOS doesn't load when read() returns less than the full ROM length
** Patch added: Fix loading of BIOS file over 9p/network filesystems https://bugs.launchpad.net/bugs/714629/+attachment/1836057/+files/rom_read.patch -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/714629 Title: BIOS doesn't load when read() returns less than the full ROM length Status in QEMU: New Bug description: When qemu is running over a 9p filesystem (e.g. when running underneath -virtfs of another qemu), and probably some other network filesystems, it fails to read its BIOS image. This is because it uses a single low-level read() call on the bios.bin, asking for the full file. However read() may return less than the full length, and it's the caller's responsibility to call it repeatedly if necessary. When read does come up short, qemu doesn't repeat the call, and reports an error instead. The attached patch fixes the one problem I saw, but I haven't tried to cover the general case (e.g. extension ROMs).
