blob: 35a43dc85c2742b2c60a0bd2c74e653657801b91 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
KVM: 0.796
semantic: 0.592
hypervisor: 0.590
performance: 0.543
architecture: 0.498
device: 0.489
network: 0.419
graphic: 0.414
arm: 0.380
peripherals: 0.361
mistranslation: 0.334
vnc: 0.332
socket: 0.318
virtual: 0.285
ppc: 0.284
kernel: 0.280
PID: 0.265
user-level: 0.251
permissions: 0.230
register: 0.217
files: 0.214
VMM: 0.202
risc-v: 0.180
boot: 0.163
TCG: 0.134
debug: 0.099
i386: 0.076
assembly: 0.054
x86: 0.048
migration wrong handling of KVM_GET_DIRTY_LOG ioctl
In the code below kvm_vm_ioctl(...) can return --errno != -1 from ioctl call, but return only checks for -1.
Found during KVM-ARM migration which apperead to go through but was actually failing getting
memslot dirty bitmap.
static int kvm_physical_sync_dirty_bitmap(....)
{
....
if(kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d) == -1) {
- err out
}
... continue
}
Sent patch for error handling:
http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg05633.html
The apparently obvious fix was applied as commit b533f658a98325d0e4 but then reverted in commit 50212d6346f33d6e19, because not all errno returns from this ioctl should be treated as errors.
That commit message said "Revert that patch instead of fixing it properly this late in the release process. I disagree with this approach, but let's make things move _somewhere_, instead of arguing endlessly whch of the 2 proposed fixes is better." -- and then we never did a proper fix, so 5 years later we're still making an incorrect == -1 check...
Moving this bug back to Confirmed to move it out of "In progress" state. We still check for only -1 upstream.
Yet another try to fix this issue:
https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg07557.html
Patch has been merged here:
https://gitlab.com/qemu-project/qemu/-/commit/38e0b7904eca7cd32
|