> -Original Message-
> From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> Sent: Thursday, January 12, 2012 6:03 PM
> To: Zhang, Yang Z
> Cc: qemu-devel@nongnu.org; a...@redhat.com; aligu...@us.ibm.com; Zhang,
> Xiantao; Shan, Haitao; k...@vger.kernel.org
> Subject: Re: [PATCH 3/3] stop t
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 2
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
>
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 fo
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
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 upda
> -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 y
> -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
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 i
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
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 dur
Hello,
On Wednesday 11 January 2012 01:56:25 Zhang, Yang Z wrote:
> > -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
> -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 l
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Monday, January 09, 2012 4:19 PM
> To: Zhang, Yang Z
> Cc: qemu-devel@nongnu.org; a...@redhat.com; aligu...@us.ibm.com; Zhang,
> Xiantao; Shan, Haitao; k...@vger.kernel.org
> Sub
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, RTCState)
> -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
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 updated
18 matches
Mail list logo
