diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/118/none/1617 | 92 | ||||
| -rw-r--r-- | results/classifier/118/none/1617114 | 78 | ||||
| -rw-r--r-- | results/classifier/118/none/1617385 | 79 |
3 files changed, 249 insertions, 0 deletions
diff --git a/results/classifier/118/none/1617 b/results/classifier/118/none/1617 new file mode 100644 index 000000000..4834d1066 --- /dev/null +++ b/results/classifier/118/none/1617 @@ -0,0 +1,92 @@ +peripherals: 0.445 +user-level: 0.420 +graphic: 0.414 +semantic: 0.410 +vnc: 0.362 +hypervisor: 0.357 +permissions: 0.353 +mistranslation: 0.329 +risc-v: 0.327 +debug: 0.320 +VMM: 0.313 +ppc: 0.306 +assembly: 0.294 +arm: 0.290 +performance: 0.288 +virtual: 0.285 +architecture: 0.275 +device: 0.268 +PID: 0.261 +network: 0.242 +TCG: 0.242 +x86: 0.232 +register: 0.212 +KVM: 0.207 +socket: 0.203 +boot: 0.191 +kernel: 0.189 +files: 0.152 +i386: 0.113 + +RISC-V: VS external IRQ can be taken in M-mode +Description of problem: +The RISC-V specification states that `VS-level interrupts and guest external interrupts are always delegated past M-mode to HS mode.` +I happened to come across a situation where QEMU takes the vs_external IRQ in machine mode. +Steps to reproduce: +1. Enable IRQs globally (mstatus, vsstatus) +2. Set hstatus.VGEIN to a legal value +3. Write -1 to mie +4. Write -1 to hvip + +I included a binary that should be able to reproduce the issue. + +I use a vectored setup for mtvec and as soon as the VSEIP bit in hvip has been set the machine jumps to mtvec.vsei. +To confirm that I actually went to mtvec and not somewhere with a faulty print I also performed an ecall and that was reported as an M mode ecall. +Additional information: +``` +TRACE: [hart_ctrl.c:35] STARTING CPU 0 +DEBUG: [trap_handling.c: 886] Setting up trap handlers +DEBUG: [aia_ctrl.c: 377] Initializing interrupt controller +TRACE: [main.c:31] Writing -1 to mie +TRACE: [main.c:33] Writing -1 to hvip +riscv_cpu_do_interrupt: hart:0, async:1, cause:000000000000000a, epc:0x0000000080000114, tval:0x0000000000000000, desc=vs_external +ERROR: [trap_handling.c:280] mtvec_vsei should be unreachable +mstatus = 0x0000000a000038a2 hstatus: + SIE = 1 VSXL[1:0] = 2 + MIE = 0 VTSR = 0 + SPIE = 1 VTW = 0 + UBE = 0 VTVM = 0 + MPIE = 1 VGEIN[5:0] = 1 + SPP = 0 HU = 0 + VS = 0 SPVP = 0 + MPP = 3 SPV = 0 + FS = 1 GVA = 0 + MPRV = 0 VSBE = 0 + SUM = 0 + MXR = 0 + TVM = 0 + TW = 0 + TSR = 0 + UXL = 2 + SXL = 2 + SBE = 0 + MBE = 0 + GVA = 0 + MPV = 0 +mie mip mideleg hvip + ssie (1) = 1 ssip (1) = 0 ssi (1) = 0 ssip (1) = 0 + vssie(2) = 1 vssip(2) = 1 vssi (2) = 0 vssip(2) = 1 + msie (3) = 1 msip (3) = 0 msi (3) = 0 msip (3) = 0 + stie (5) = 1 stip (5) = 0 sti (5) = 0 stip (5) = 0 + vstie(6) = 1 vstip(6) = 0 vsti (6) = 0 vstip(6) = 0 + mtie (7) = 1 mtip (7) = 0 mti (7) = 0 mtip (7) = 0 + seie (9) = 1 seip (9) = 0 sei (9) = 0 seip (9) = 0 + vseie(10) = 1 vseip(10) = 1 vsei (10) = 0 vseip(10) = 1 + meie (11) = 1 meip (11) = 0 mei (11) = 0 meip (11) = 0 + sgeie(12) = 1 sgeip(12) = 0 sgei (12) = 0 sgeip(12) = 0 +DEBUG: [trap_handling.c: 28] hart_ctrl.kill_hart = 0x8000a00c +TRACE: [trap_handling.c:29] Program done, exiting +QEMU: Terminated +``` +Reproducer of the problem: +[main](/uploads/26a5698ce948149ca9d34f6b3dfac6a4/main) diff --git a/results/classifier/118/none/1617114 b/results/classifier/118/none/1617114 new file mode 100644 index 000000000..c7318949e --- /dev/null +++ b/results/classifier/118/none/1617114 @@ -0,0 +1,78 @@ +semantic: 0.776 +graphic: 0.680 +mistranslation: 0.661 +user-level: 0.650 +register: 0.648 +peripherals: 0.579 +x86: 0.555 +virtual: 0.551 +ppc: 0.545 +hypervisor: 0.544 +network: 0.541 +permissions: 0.538 +device: 0.525 +performance: 0.520 +debug: 0.507 +PID: 0.496 +architecture: 0.454 +boot: 0.453 +files: 0.450 +kernel: 0.428 +socket: 0.407 +arm: 0.402 +risc-v: 0.388 +KVM: 0.388 +vnc: 0.375 +TCG: 0.362 +VMM: 0.336 +assembly: 0.310 +i386: 0.279 + +Qemu 2.6.0 freezes with windows guests + +When launching qemu with the same command line as before 2.6.0, with SDL display, with virtio, for a win-10 guest: + +qemu-system-x86_64 -enable-kvm -name win-10 -machine type=pc,accel=kvm -cpu host -smp cores=1,threads=2,sockets=1 -m 2.7G -balloon virtio -drive file=/home/<username>/.qemu/imgs/win10-coe.qcow2,index=0,media=disk,if=virtio -drive file=/usr/share/virtio/virtio-win.iso,index=1,media=cdrom -drive file=/usr/share/spice-guest-tools/spice-guest-tools.iso,index=2,media=cdrom -net nic,model=virtio -net tap,ifname=tap0,script=no,downscript=no,vhost=on -usbdevice tablet -usb -display sdl -vga qxl -soundhw ac97 -rtc base=localtime -usbdevice host:0b0e:0032 -usbdevice host:0b0e:0348 -usbdevice host:0b0e:0410 + +Qemu at some point just freezes with no error message at all with newer version 2.6.0-1. + +Reverting to prior version 2.5.1-1, things go back to normal. + +A simple way to accelerate the freeze is to have qemu launch in a workspace/desktop, and then move to a different workspace/desktop, and then move back to the qemu workspace/desktop, and you'll find out it's frozen. + +BTW, there's no way to get into qemu monitor mode terminal at all once frozen. The monitor terminal shows up, but does nothing... + +Perhaps it's useful to notice that I have up to date win-10 virtio drivers for ethernet, scsi/storage, qxl-dod, balloon, and serial interface drivers. The ISO version used is 0.1.118.1 (virtio-win AUR package). + +Using the standard (std) qemu video driver, rather than the qxl-dod one makes no difference BTW. + +Just in case, running on up to date x86-64 Arch, plain qemu command line. + +Can you please try with 2.6.1 or 2.7.0-rc4? + +Tested 2.6.1, fails/freezes the same way, :-( + +Tested as well 2.7.0, and it now fails on windows start with: + +KMODE_EXCEPTION_NOT_HANDLED (viostor.sys) + +Notice 2.5.1 still works just fine. + +Qemu 2.8.0 is no better. Actually now win-10 can even boot, getting the light blue window with sad face saying: "Your PC ran into a problem and needs to restart...". Moreover, the qemu monitor mode (alt-2) pops up a frozen useless window, so no way to try reseting... + +More narrowed now, :-) + +With 2.8.0 qemu keeps freezing bad, when used with "-display sdl". However when used with "-display gtk" or "-display none", then it doesn't freeze. + +So it seems "-display sdl" is the one totally breaking windows guest on qemu. + +Notice that if I don't try other displays, then I wouldn't even notice it was just the SDL display. + +If there's no intention on fixing SDL, given other alternatives are available, in particular a GTK one for displaying the graphics output, then I'm OK with a "no fix" for this. + +As a bonus, it seems no display (-display none), with current qxl-dod windows driver from Fedora project, seems to be working fine with spice. That was not working before... So getting away from SDL display now. But no sure if this means SDL never again? :-) + +Which version of SDL were you using here? SDL 1.2 or SDL 2.0? If you were using SDL 1.2, could you please try with SDL 2.0 instead? Support for 1.2 has been removed now... + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/none/1617385 b/results/classifier/118/none/1617385 new file mode 100644 index 000000000..b397b976f --- /dev/null +++ b/results/classifier/118/none/1617385 @@ -0,0 +1,79 @@ +graphic: 0.777 +device: 0.747 +performance: 0.649 +user-level: 0.629 +virtual: 0.604 +hypervisor: 0.556 +PID: 0.543 +mistranslation: 0.530 +arm: 0.462 +semantic: 0.451 +register: 0.448 +architecture: 0.415 +ppc: 0.407 +peripherals: 0.394 +socket: 0.359 +files: 0.336 +VMM: 0.277 +x86: 0.276 +boot: 0.273 +permissions: 0.272 +kernel: 0.259 +assembly: 0.236 +network: 0.215 +i386: 0.191 +risc-v: 0.182 +vnc: 0.174 +debug: 0.170 +TCG: 0.151 +KVM: 0.062 + +No snapshot possible with virtio-gpu activated + +I'm using "Qemu" and "Virtual Machine Manager" on Debian-8-Stretch - both newest versions out of the Debian-testing-repository (state 26.08.2016). + +If I try to save a virtual machine, it fails and I'll get the following error: + +libvirtError: internal error: unable to execute QEMU command 'migrate': State blocked by non-migratable device '0000:00:02.0/virtio-gpu' + +This only happens, if I chose "Virtio" as graphics-driver (no matter if I use "Spice" or "Vnc" as Server by the way). If I switch to any other driver (Cirrus, Qxl, Vga, VMvga...) there is no problem to take a snapshot and save the virtual machine. + +Unfortunately "virtio-gpu" (together with "Spice-Server") is the only driver that provides proper working/running my virtual machines on my PC. + +feuerkogel1 + +Hi + You should find in current qemu that virtio-gpu migrates unless you've enabled the virgl 3d graphics +code. WHat version of the qemu package are you using? If it's old then I suggest you open a debian +bug against it. + +Dave + +Hello, + +I'm using Qemu-version "1:2.6+dfsg-3" together with virt-manager-version +"1:1.4.0-3: all", as I've written, out of the regular +Debian-testing-repository (Stretch)... + +Jack + + +Am 2016-09-05 um 16:56 schrieb Dr. David Alan Gilbert: +> Hi +> You should find in current qemu that virtio-gpu migrates unless you've enabled the virgl 3d graphics +> code. WHat version of the qemu package are you using? If it's old then I suggest you open a debian +> bug against it. +> +> Dave +> +> ** Changed in: qemu +> Status: New => Incomplete +> + + +[Expired for QEMU because there has been no activity for 60 days.] + +I also have this problem, with the 3D acceleration enabled, it would be great if the situation improves as the VM often not stable after the host restores from sleep state. + +This bug tracker here is not active anymore. If you want to report bugs, please open a new ticket at https://gitlab.com/qemu-project/qemu/-/issues , thanks. + |