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
