qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/4] xen: introduce mc146818rtcxen


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 1/4] xen: introduce mc146818rtcxen
Date: Mon, 21 Nov 2011 14:49:32 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 11/20/2011 08:53 AM, Avi Kivity wrote:
On 11/18/2011 04:54 PM, Anthony Liguori wrote:

Thinking more about it, I think this entire line of thinking is wrong
(including mine) :-)

The problem you're trying to solve is that the RTC fires two 1 second
timers regardless of whether the guest is reading the wall clock time,
right?  And since wall clock time is never read from the QEMU RTC in
Xen, it's a huge waste?

The Right Solution would be to modify the RTC emulation such that it
did a qemu_get_clock() during read of the CMOS registers in order to
ensure the time was up to date (instead of using 1 second timers).

Then the timers wouldn't even exist anymore.

That would make host time adjustments (suspend/resume) be reflected in
the guest.

qemu_get_clock(rtc_clock)

It depends on what clock rtc_clock is tied too. If it's tied to vm_clock, it won't be affected.

Not sure if that's good or bad, but it's different.

Doing this wouldn't change the behavior. I presume you were confusing qemu_get_clock() with qemu_get_timedate().

But our current default behavior has the characteristic that you're concerned about. It's was a conscious decision. See:

commit 6875204c782e7c9aa5c28f96b2583fd31c50468f
Author: Jan Kiszka <address@hidden>
Date:   Tue Sep 15 13:36:04 2009 +0200

    Enable host-clock-based RTC

Regards,

Anthony Liguori



reply via email to

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