qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [Bug 1797033] Re: Running with -rtc clock=vm, base=<datetim


From: Artem Pisarenko
Subject: [Qemu-devel] [Bug 1797033] Re: Running with -rtc clock=vm, base=<datetime> introduces arbitrary base shift at guest startup
Date: Wed, 10 Oct 2018 05:39:49 -0000

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]