-Original Message-
From: Paolo Bonzini [mailto:pbonz...@redhat.com]
Sent: Wednesday, February 22, 2012 7:19 PM
0) My alarm tests failed quite badly. :( I attach a patch for kvm-unit-tests
(repository at git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git).
The tests can be
On 02/24/2012 01:55 AM, Zhang, Yang Z wrote:
Hi paolo The DM and 24/12 test case assumes the changing of DM bit
will reflect to RTC internal clock. But the datasheet said nothing
will affect if you change it. Also, the current logic in qemu has the
same assumption. Does this a bug or just by
On 02/21/2012 01:00 AM, Zhang, Yang Z wrote:
Thanks, this looks much better! I'll run it through some tests.
We also should try to keep migration working from older versions using the
load_old callback.
Sure, I missed it. Will add it to the version 3.
Any other comments?
Here they
-Original Message-
From: Paolo Bonzini [mailto:pbonz...@redhat.com]
Sent: Wednesday, February 22, 2012 7:19 PM
0) My alarm tests failed quite badly. :( I attach a patch for kvm-unit-tests
(repository at git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git).
The tests can be
On 02/23/2012 02:49 AM, Zhang, Yang Z wrote:
6) Setting the clock after 500 ms happens not on every set, but only when
moving
out of divider reset (register A bits 5-7 moving from 110 or 111 to 010).
As far as
I can read, SET prevents the registers from changing value, but keeps the
On 02/23/2012 02:49 AM, Zhang, Yang Z wrote:
Currently they hang very early because UF is not set. I
attempted to fix that, but ran into other problems. UIP seems
not to be really in sync with the update interrupt, because the
500 ms update tests pass when testing UIP, but not when testing
-Original Message-
From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
Bonzini
Sent: Monday, February 20, 2012 3:41 PM
On 02/20/2012 01:24 AM, Zhang, Yang Z wrote:
Changes in v2:
Add UIP check logic.
Add logic that next second tick will occur in exactly
On 02/20/2012 01:24 AM, Zhang, Yang Z wrote:
Changes in v2:
Add UIP check logic.
Add logic that next second tick will occur in exactly 500ms later after
setting the clock
Current RTC emulation uses periodic timer(2 timers per second) to update RTC
clock. And it will stop CPU staying at