qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Juan Quintela <quintela@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Re: Host clock broke loadvm
Date: Thu, 08 Oct 2009 11:31:09 +0200	[thread overview]
Message-ID: <4ACDB15D.3070607@siemens.com> (raw)
In-Reply-To: <m3pr8yna7s.fsf@neno.mitica>

Juan Quintela wrote:
> Hi Jan
> 
> Today I found that I am not able to load anymore old saved images (old
> means more than 2 days old).  Problem is with host clock.
> 
> I need to run qemu with -rtc clock=vm, and then things cames to work
> again.
> 
> My suspicion is that the saved timers are based from cpu_clock_offset,
> and when we run now with host_clock, that value don't exist.
> 
> If I don't use -rtc clock=vm, machines will come eventually to life, but
> it will take several minutes.

That makes sense as you cannot simply migrate timers between clocks (in
this case, you would have to patch the timeout value of the rtc timer
after resume).

> 
> Anthony asked to change pc-11 definition to use vm clock.  What do you
> think?

Definitely makes sense, also for other reasons unrelated to save/restore.

>  Any other good idea to make a machine saved with clock=vm to
> load with clock=host.
> 
> I tried the trial:
> 
> if (cpu_clock_offset != 0)
>    rtc_clock = vm_clock;
> 
> after loading an image, but that didn't fixed the problem (I didn't
> investigate more).
> 
> Do you have a plan to go from here?

I would say, first go for clock=vm for pc-11. Until someone comes up
with a good reason to migrate from clock=vm to clock=host, don't try to
be smarter than required.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

      reply	other threads:[~2009-10-08  9:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-07 21:52 [Qemu-devel] Host clock broke loadvm Juan Quintela
2009-10-08  9:31 ` Jan Kiszka [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ACDB15D.3070607@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).