diff options
Diffstat (limited to 'results/classifier/118/none/1855617')
| -rw-r--r-- | results/classifier/118/none/1855617 | 91 |
1 files changed, 91 insertions, 0 deletions
diff --git a/results/classifier/118/none/1855617 b/results/classifier/118/none/1855617 new file mode 100644 index 000000000..fe73b88c8 --- /dev/null +++ b/results/classifier/118/none/1855617 @@ -0,0 +1,91 @@ +user-level: 0.583 +graphic: 0.526 +peripherals: 0.507 +PID: 0.500 +device: 0.495 +arm: 0.493 +permissions: 0.484 +network: 0.481 +virtual: 0.460 +mistranslation: 0.447 +performance: 0.442 +semantic: 0.442 +vnc: 0.442 +KVM: 0.435 +ppc: 0.433 +hypervisor: 0.429 +files: 0.418 +risc-v: 0.414 +kernel: 0.402 +architecture: 0.398 +VMM: 0.398 +x86: 0.383 +socket: 0.380 +register: 0.378 +boot: 0.366 +assembly: 0.353 +i386: 0.323 +debug: 0.318 +TCG: 0.307 + +savevm with hax saves wrong register state + +I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different. +When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot. + +cc'ing Colin and Yu for Hax info: + +* Alex (<email address hidden>) wrote: +> Public bug reported: +> +> I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different. +> When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1855617 +> +> Title: +> savevm with hax saves wrong register state +> +> Status in QEMU: +> New +> +> Bug description: +> I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different. +> When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1855617/+subscriptions +> +-- +Dr. David Alan Gilbert / <email address hidden> / Manchester, UK + + + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/188 + + |