Comments

On 20 January 2012 13:06, Paolo Bonzini <pbonzini@redhat.com> wrote:
> This lets the user specify the desired semantics. By default, the RTC> will follow adjustments from the host's NTP client. "-rtc clock=vm" will> improve determinism with both icount and qtest. Finally, the previous> behavior is available with "-rtc clock=rt".
Generally this makes sense except for the omap1 "lpg" module where the
clock state is not visible to the guest, only to the host. It
emulates a blinking led.
Cheers

On 02/17/2012 08:09 AM, andrzej zaborowski wrote:
>> > This lets the user specify the desired semantics. By default, the RTC>> > will follow adjustments from the host's NTP client. "-rtc clock=vm" will>> > improve determinism with both icount and qtest. Finally, the previous>> > behavior is available with "-rtc clock=rt".> Generally this makes sense except for the omap1 "lpg" module where the> clock state is not visible to the guest, only to the host. It> emulates a blinking led.
Ok, then I think it's better to switch that one to vm_clock (so that you
could use it as a deterministic debugging aid with -icount, for
example). What do you think?
Paolo

On 17 February 2012 09:05, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 02/17/2012 08:09 AM, andrzej zaborowski wrote:>>> > This lets the user specify the desired semantics. By default, the RTC>>> > will follow adjustments from the host's NTP client. "-rtc clock=vm" will>>> > improve determinism with both icount and qtest. Finally, the previous>>> > behavior is available with "-rtc clock=rt".>> Generally this makes sense except for the omap1 "lpg" module where the>> clock state is not visible to the guest, only to the host. It>> emulates a blinking led.>> Ok, then I think it's better to switch that one to vm_clock (so that you> could use it as a deterministic debugging aid with -icount, for> example). What do you think?
I was thinking about potential visual effects. But perhaps you were
right with the first approach, i.e. debugging -> deterministic (which
in this case would ideally also use the frequency derived from the
system clock passed to omap_lpg_init), normal work -> realtime. I'll
just push the original patch then, if you're ok with that.
Cheers

On 02/17/2012 09:24 AM, andrzej zaborowski wrote:
>> > Ok, then I think it's better to switch that one to vm_clock (so that you>> > could use it as a deterministic debugging aid with -icount, for>> > example). What do you think?> I was thinking about potential visual effects.
vm_clock is the same as rt_clock as long as: 1) you don't use -icount;
2) you don't stop the VM.
Not pulsing the LED when the VM is stopped seems okay, so I think
switching from rt_clock to vm_clock is the right thing to do.
> But perhaps you were> right with the first approach, i.e. debugging -> deterministic (which> in this case would ideally also use the frequency derived from the> system clock passed to omap_lpg_init), normal work -> realtime.
You should get this from -icount if you just use vm_clock.
The overall series doesn't apply anymore, I'll split omap_lpg into its
own patch and resend.
Paolo