* [Qemu-devel] [Bug 1797033] [NEW] Running with -rtc clock=vm, base=<datetime> introduces arbitrary base shift at guest startup
@ 2018-10-10 5:38 Artem Pisarenko
2018-10-10 5:39 ` [Qemu-devel] [Bug 1797033] " Artem Pisarenko
2018-12-12 9:19 ` Thomas Huth
0 siblings, 2 replies; 3+ messages in thread
From: Artem Pisarenko @ 2018-10-10 5:38 UTC (permalink / raw)
To: qemu-devel
Public bug reported:
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.)
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1797033
Title:
Running with -rtc clock=vm,base=<datetime> introduces arbitrary base
shift at guest startup
Status in QEMU:
New
Bug description:
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.)
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1797033/+subscriptions
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Qemu-devel] [Bug 1797033] Re: Running with -rtc clock=vm, base=<datetime> introduces arbitrary base shift at guest startup
2018-10-10 5:38 [Qemu-devel] [Bug 1797033] [NEW] Running with -rtc clock=vm, base=<datetime> introduces arbitrary base shift at guest startup Artem Pisarenko
@ 2018-10-10 5:39 ` Artem Pisarenko
2018-12-12 9:19 ` Thomas Huth
1 sibling, 0 replies; 3+ messages in thread
From: Artem Pisarenko @ 2018-10-10 5:39 UTC (permalink / raw)
To: qemu-devel
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)?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1797033
Title:
Running with -rtc clock=vm,base=<datetime> introduces arbitrary base
shift at guest startup
Status in QEMU:
New
Bug description:
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.)
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1797033/+subscriptions
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Qemu-devel] [Bug 1797033] Re: Running with -rtc clock=vm, base=<datetime> introduces arbitrary base shift at guest startup
2018-10-10 5:38 [Qemu-devel] [Bug 1797033] [NEW] Running with -rtc clock=vm, base=<datetime> introduces arbitrary base shift at guest startup Artem Pisarenko
2018-10-10 5:39 ` [Qemu-devel] [Bug 1797033] " Artem Pisarenko
@ 2018-12-12 9:19 ` Thomas Huth
1 sibling, 0 replies; 3+ messages in thread
From: Thomas Huth @ 2018-12-12 9:19 UTC (permalink / raw)
To: qemu-devel
Fix has been included here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=eb6a52099160f1a6e66d7e
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1797033
Title:
Running with -rtc clock=vm,base=<datetime> introduces arbitrary base
shift at guest startup
Status in QEMU:
Fix Released
Bug description:
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.)
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1797033/+subscriptions
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-12-12 9:31 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-10 5:38 [Qemu-devel] [Bug 1797033] [NEW] Running with -rtc clock=vm, base=<datetime> introduces arbitrary base shift at guest startup Artem Pisarenko
2018-10-10 5:39 ` [Qemu-devel] [Bug 1797033] " Artem Pisarenko
2018-12-12 9:19 ` Thomas Huth
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.