I am running an experiment with QEMU as follows -
1. Start the QEMU process with "accel=kvm" using the default qemu64 CPU, the command line I use is -
sudo ./qemu-system-x86_64 -m 1024 -machine pc-i440fx-2.5 -cpu qemu64,-kvmclock -accel kvm -netdev tap,id=tap1,ifname=tap0,script=no,downscript=no -device virtio-net-pci,netdev=tap1,mac=00:00:00:00:00:00 -drive file=~/os_images_for_qemu/ubuntu-16.04.server.qcow2,format=qcow2,if=none,id=img-direct -device virtio-blk-pci,drive=img-direct
2. After starting a small application on the guest, I perform a save of the VMState by running "stop + savevm + c" on the QEMU monitor command line.
3. The savevm process successfully completes and the VM resumes execution of the guest.
4. Later, I load the saved snapshot of the VM without "accel=kvm" as follows -
sudo ./qemu-system-x86_64 -m 1024 -machine pc-i440fx-2.5 -netdev tap,id=tap1,ifname=tap0,script=no,downscript=no -device virtio-net-pci,netdev=tap1,mac=00:00:00:00:00:00 -drive file=~/os_images_for_qemu/ubuntu-16.04.server.qcow2,format=qcow2,if=none,id=img-direct -device virtio-blk-pci,drive=img-direct
-loadvm -loadvm vm-20200926170429 -d in_asm,cpu,exec,nochain
This is the start of the trace -
Servicing hardware INT=0x71
----------------
IN:
0xffffffff8184f6e8: 6a 0e pushq $0xe
0xffffffff8184f6ea: e9 11 04 00 00 jmp 0xffffffff8184fb00
I want to understand what is the source of the interrupt right at the start of the trace. Is this a genuine interrupt that came from the KVM mode or is this a result of some savevm/loadvm magic ? Is there something wrong with my experiment that enables the generation of these interrupts ?
Note:
I use Qemu-3.0.0 and my host and target architectures are both x86_64. The guest runs a 4.4.0-116-generic linux kernel.
Regards,
Arnab