Hi all,
I was told on IRC to use this ML to report the following bug.
It seems that there is something wrong with QEMU with respect to handle the
singlestepping and AMD64 syscall instruction.
The AMD "syscall" instruction will clear defined flag in the FMASK MSR. Normally
the TF flag is set there, so the first instruction when kernel is entered after
syscall won't cause single step exception in the kernel.
The observed scenario is a unhandled singlestep fault in the kernel or host
reboot or QEMU crash.
The possible way how to reproduce it is to single step through any function
which does "syscall" instruction. After syscall is entered QEMU will trigger
singlestepping exception in the kernel despite that the TF is set in FMASK MSR.
Real HW behaves correctly and does not trigger this exception.
What is interesting is that I was not able to trigger it if I just enabled TF
and did the syscall instruction, perhaps for this bug is somewhat important to
have TF set for previous few instruction.
I have stumbled to this problem while working with our custom OS. However after
some googling I found out that the NetBSD guys (CCed) are having very similar
problem and I asked them to prepare a ISO image where the problem ends with QEMU
SIGSEGV or host reboot.
You can check original report here:
http://gnats.netbsd.org/49603
The way how to reproduce the problem with NetBSD is pasted to the end of this
email.
Unfortunately all I was able to do is to verify that QEMU has a code to clear
RFLAGS based on FMASK MSR. Any other help is very appreciated.
Thanks,
Rudolf
Hi Rudolf,
Here's a more Linux-friendly recipe for reproducing the bug. A couple of
gigabytes of of free disk space are needed for the uncompressed OS image.
wget
http://www.gson.org/bugs/qemu/NetBSD-amd64-2015.08.01.16.18.47-com0.img.gz
gunzip NetBSD-amd64-2015.08.01.16.18.47-com0.img.gz
qemu-system-x86_64 -nographic -snapshot
NetBSD-amd64-2015.08.01.16.18.47-com0.img
(wait for the qemu guest to boot to a login prompt)
(log in as root; there is no password)
gdb /bin/sync
break sync
run
stepi
stepi
stepi
(The qemu guest will either instantly reboot or hang, or qemu will segfault)
(On real hardware, you just get another gdb prompt, and gdb is still
responding)
--
S přátelským pozdravem / Best regards / Mit freundlichen Grüßen
Ing. Rudolf Marek
SYSGO s.r.o.
Zelený pruh 99
CZ-14800 Praha 4
Phone: +420 222138 111, +49 6136 9948 111
Fax: +420 296374890, +49 6136 9948 1 111
rudolf.ma...@sysgo.com
http://www.sysgo.com | http://www.elinos.com | http://www.pikeos.com
