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

[Anthony Liguori <anthony@xxxxxxxxxxxxx>]

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 <jan.kiszka@xxxxxxxxxxx>
Date:   Tue Sep 15 13:36:04 2009 +0200

    Enable host-clock-based RTC

Regards,

Anthony Liguori

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel