blob: d4aad4ac4bbbb12c78727bde523393a985bac9c4 (
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
|
performance: 0.501
device: 0.450
graphic: 0.334
ppc: 0.327
semantic: 0.280
boot: 0.265
vnc: 0.239
socket: 0.187
architecture: 0.181
register: 0.180
risc-v: 0.163
files: 0.147
mistranslation: 0.136
virtual: 0.135
x86: 0.125
hypervisor: 0.122
PID: 0.119
debug: 0.118
kernel: 0.115
network: 0.113
arm: 0.105
VMM: 0.087
i386: 0.078
user-level: 0.076
permissions: 0.067
TCG: 0.067
KVM: 0.057
peripherals: 0.052
assembly: 0.023
Running with -rtc clock=vm,base=<datetime> introduces arbitrary base shift at guest startup
When specifying 'base' for RTC to start with, it has incorrect implementation in combination with clock=vm.
I inspected source code. This is because it uses host clock (qemu_time() function return value) as reference with 'rtc_date_offset' operations across several places in code before guest execution starts, which has no relevance with clock=vm.
It works in vast majority of cases only thanks to combination of some luck and fast execution of qemu initialization phase relative to host real time (i.e. multiple calls of qemu_time() returns same value). But if qemu execution is being slow down by high CPU load on host or started just before value of second changes, it may accumulate at least 1 second (and in hard circumstances even 2+ seconds) of delay from specified base datetime before guest becomes ready to start.
This behavior breaks determinism of guest execution in icount mode. (Even if guest doesn't cares about precise time, just one second shift may trigger such chain of changes which accumulates significant difference in guest state at the moment when guest OS finishes booting.)
Why I didn't posted patch to qemu-devel ?
I have no idea how to patch it correctly, because it isn't clear how these things are expected to work when referenced across all qemu code and different use cases. Should vl.c/qemu_get_timedate() just be fixed ? Does each caller expect same behavior from it? Or only selected hw/* RTC implementations (such as hw/timer/mc146818rtc.c) have to be modified to use alternative function ? Or maybe it isn't specific to clock=vm and should be considered bad behavior in any case (i.e. time shouldn't advance before guest execution being started)?
Fix has been included here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=eb6a52099160f1a6e66d7e
|