On 01/12/2012 01:00 AM, Zhang, Yang Z wrote:
Regarding the UIP bit, a guest could read it in a loop and wait
for the value to change. But you can emulate it in
cmos_ioport_read by reading the host time, that is, return 1
during 244us, 0 for remaining of the second, and have that in
sync with
On 01/12/2012 01:51 AM, Zhang, Yang Z wrote:
QEMU not being a simulator means that we always assume that the RTC is
programmed for a 32768 Hz clock, for example, because any other setting would
not make sense on a PC. We can use a 1-second (or higher, as in your patches)
timer, rather than a
On Thu, Jan 12, 2012 at 12:00:06AM +, Zhang, Yang Z wrote:
-Original Message-
From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
Regarding the UIP bit, a guest could read it in a loop and wait for the
value to
change. But you can emulate it in cmos_ioport_read by reading
On Thu, Jan 12, 2012 at 07:59:06AM -0200, Marcelo Tosatti wrote:
On Thu, Jan 12, 2012 at 12:00:06AM +, Zhang, Yang Z wrote:
-Original Message-
From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
Regarding the UIP bit, a guest could read it in a loop and wait for the
the periodic RTC update timer
On Thu, Jan 12, 2012 at 07:59:06AM -0200, Marcelo Tosatti wrote:
On Thu, Jan 12, 2012 at 12:00:06AM +, Zhang, Yang Z wrote:
-Original Message-
From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
Regarding the UIP bit, a guest could read
On Thu, Jan 12, 2012 at 10:26:17AM +0100, Paolo Bonzini wrote:
On 01/12/2012 01:00 AM, Zhang, Yang Z wrote:
Regarding the UIP bit, a guest could read it in a loop and wait
for the value to change. But you can emulate it in
cmos_ioport_read by reading the host time, that is, return 1
during
On 01/12/2012 11:20 AM, Marcelo Tosatti wrote:
The point is not_correctness_. It is_atomicity_.
Quoting you earlier
This is incorrect, for two reasons. First, the UIP is in the spec,
and we have to implement it. Second, reading the clock is not atomic,
and waiting for UIP=0 gives you 220
On Fri, Jan 06, 2012 at 07:37:31AM +, Zhang, Yang Z wrote:
change the RTC update logic to use host time with offset to calculate RTC
clock.
There have no need to use two periodic timers to maintain an internal
timer for RTC clock update and alarm check. Instead, we calculate the
-Original Message-
From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
Regarding the UIP bit, a guest could read it in a loop and wait for the value
to
change. But you can emulate it in cmos_ioport_read by reading the host time,
that is, return 1 during 244us, 0 for remaining of
-Original Message-
From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
Bonzini
Because it's not in the spec because some engineer thought it was cool.
It not cool. We need to do some optimizations to get Better Performance.
It's in the spec because it gives you a
On 01/10/2012 07:37 AM, Zhang, Yang Z wrote:
Also, I'm not sure if the update in progress flag still works.
Clients are supposed to wait for UIP=0 before reading the RTC,
and an update is supposed to be at least 220 microseconds away
when UIP=0.
Hardware need a period time to update clock and
-Original Message-
From: Paolo Bonzini [mailto:pbonz...@redhat.com]
Sent: Tuesday, January 10, 2012 5:25 PM
Also, I'm not sure if the update in progress flag still works.
Clients are supposed to wait for UIP=0 before reading the RTC, and an
update is supposed to be at least 220
On 01/11/2012 01:56 AM, Zhang, Yang Z wrote:
Clients are supposed to wait for UIP=0 before reading the RTC,
and an update is supposed to be at least 220 microseconds away
when UIP=0.
Hardware need a period time to update clock and it would not
provide the right value during the update. So
On 01/06/2012 08:37 AM, Zhang, Yang Z wrote:
VMSTATE_BUFFER(cmos_data, RTCState),
VMSTATE_UINT8(cmos_index, RTCState),
-VMSTATE_INT32(current_tm.tm_sec, RTCState),
-VMSTATE_INT32(current_tm.tm_min, RTCState),
-VMSTATE_INT32(current_tm.tm_hour,
: [PATCH 3/3] stop the periodic RTC update timer
On 01/06/2012 08:37 AM, Zhang, Yang Z wrote:
VMSTATE_BUFFER(cmos_data, RTCState),
VMSTATE_UINT8(cmos_index, RTCState),
-VMSTATE_INT32(current_tm.tm_sec, RTCState),
-VMSTATE_INT32(current_tm.tm_min
-Original Message-
From: Jan Kiszka [mailto:jan.kis...@web.de]
Sent: Saturday, January 07, 2012 1:27 AM
However, not having looked at details yet, two things jumped at me:
- You cannot simply change the vmstate format without caring about
migration from older qemu versions.
On 2012-01-06 05:37, Zhang, Yang Z wrote:
change the RTC update logic to use host time with offset to calculate RTC
clock.
There have no need to use two periodic timers to maintain an internal
timer for RTC clock update and alarm check. Instead, we calculate the real
RTC time by the
change the RTC update logic to use host time with offset to calculate RTC clock.
There have no need to use two periodic timers to maintain an internal
timer for RTC clock update and alarm check. Instead, we calculate the real RTC
time by the host time with an offset. For alarm and
18 matches
Mail list logo
