[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Error handling for KVM_GET_DIRTY_LOG
From: |
Janosch Frank |
Subject: |
[Qemu-devel] Error handling for KVM_GET_DIRTY_LOG |
Date: |
Thu, 16 Feb 2017 15:51:17 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 |
While trying to fix a bug in the s390 migration code, I noticed that
QEMU ignores practically all errors returned from that VM ioctl. QEMU
behaves as specified in the KVM api and only processes -1 (-EPERM) as an
error.
Unfortunately the documentation is wrong/old and KVM may return -EFAULT,
-EINVAL, -ENOTSUPP (BookE) and -ENOENT. This bugs me, as I found a case
where I want to return -EFAULT because of guest memory problems and QEMU
will still happily migrate the VM.
I currently don't see a reason why we continue to migrate on EFAULT and
EINVAL. But returning -error from kvm_physical_sync_dirty_bitmap might
also a bit hard, as it kills QEMU.
Do we want to fix this and if, how do we want it done?
If not we at least have a definitive mail to point to when the next one
comes around. I also have a KVM patch to update the api documentation if
wanted (maybe we should dust that off a bit anyhow).
This has been brought up in 2009 [1] the first time and was more or less
fixed and then reverted in 2014 [2].
The reason in [1] was that PPC hadn't settled yet on a valid return code.
In [2] it was too close to the v2 to handle it properly.
[1] https://lists.nongnu.org/archive/html/qemu-devel/2009-07/msg01772.html
[2] https://lists.nongnu.org/archive/html/qemu-devel/2014-04/msg01993.html
Cheers,
Janosch
- [Qemu-devel] Error handling for KVM_GET_DIRTY_LOG,
Janosch Frank <=