Re: [Qemu-devel] [PATCH V3] rtc: fix a infinite loop in windows vmstartup

Re: [Qemu-devel] [PATCH V3] rtc: fix a infinite loop in windows vmstartup

[peng.hao2]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

I'm sorry I copy and paste code to make a patch, but I make a mistake to send a uncompleted patch.



















彭浩 penghao






IT开发工程师 IT Development
Engineer
操作系统产品部/中心研究院/系统产品 OS Product Department/Central R＆D Institute/System Product









成都市天府大道中段800号中兴大厦A座 
T: +86 028 18123274005
E: peng.hao2@zte.com.cn 
www.zte.com.cn








Original Mail



Sender:  <eblake@redhat.com>
To: PengHao10096742 <mst@redhat.com> <pbonzini@redhat.com>
CC: LiuYi10066463 <qemu-devel@nongnu.org>
Date: 2017/07/24 19:55
Subject: Re: [Qemu-devel] [PATCH V3] rtc: fix a infinite loop in windows vmstartup





On 07/24/2017 01:35 PM, Peng Hao wrote:
> When a windows vm starts, periodic timer of rtc will stop several times.
> windows kernel will check whether REG_A_UIP is changed. REG_C's interrupt
> flags will not be cleared when periodic timer stops and the update timer
> will switch to alarm timer. So the expiration time of alarm timer is very
> long and REG_A_UIP will not vary.At last windows kernel will repeat to 
> check REG_A_UIP all the time.
> 
> Signed-off-by: Peng Hao <peng.hao2@zte.com.cn>
> Signed-off-by: Liu Yi <liu.yi24@zte.com.cn>
> ---

When posting a v3, it's useful to tell us (after the --- separator) what
changed from v2, to help us focus on why a v3 was needed.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

[-- Attachment #2: 24242e5637af428891c4db731e7765ad.jpg --]
[-- Type: image/jpeg, Size: 2064 bytes --]

[-- Attachment #3: 9ae3e214c17d49ed935d87c674ba3ee2.jpg --]
[-- Type: image/jpeg, Size: 6015 bytes --]

Re: [Qemu-devel] [PATCH V3] rtc: fix a infinite loop in windows vmstartup

[peng.hao2]

>On 25/07/2017 06:14, peng.hao2@zte.com.cn wrote:





>>> On 24/07/2017 20:35, Peng Hao wrote:
>> 
>> 
>> 
>> 
>> 
>>>> When a windows vm starts, periodic timer of rtc will stop several times.
>>>> windows kernel will check whether REG_A_UIP is changed. REG_C's interrupt
>>>> flags will not be cleared when periodic timer stops and the update timer
>>>> will switch to alarm timer. So the expiration time of alarm timer is very
>>>> long and REG_A_UIP will not vary.At last windows kernel will repeat to 
>>>> check REG_A_UIP all the time.
>> 
>>> This should not happen.  REG_A_UIP is set and cleared in register A
>>> every second, like this:
>>>        case RTC_REG_A:
>>>            if (update_in_progress(s)) {
>>>                s->cmos_data[s->cmos_index] |= REG_A_UIP
>>>            } else {
>>>                s->cmos_data[s->cmos_index] &= ~REG_A_UIP
>>>            }
>>>            ret = s->cmos_data[s->cmos_index]
>>>            break
>> 
>> 
>> 
>> when periodic timer stop, update timer is set to a long expire time (as alarm timer).

>I think I see the bug now:

>diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c
>index 1b8d3d7d4c..6184b4378e 100644
>--- a/hw/timer/mc146818rtc.c
>+++ b/hw/timer/mc146818rtc.c
>@@ -321,9 +321,11 @@ static void check_update_timer(RTCState *s)
>     s->next_alarm_time = next_update_time +
>                          (next_alarm_sec - 1) * NANOSECONDS_PER_SECOND
> 
>-    if (s->cmos_data[RTC_REG_C] & REG_C_UF) {
>-        /* UF is set, but AF is clear.  Program the timer to target
>-         * the alarm time.  */
>+    if ((s->cmos_data[RTC_REG_C] & REG_C_UF) &&
>+        !(s->cmos_data[RTC_REG_A] & REG_A_UIP)) {
>+        /* If UIP was latched, we need to clear it at the next update.
>+         * Otherwise, if UF is set we only need to program the timer to
>+         * target the alarm time.  */
>         next_update_time = s->next_alarm_time
>     }
>     if (next_update_time != timer_expire_time_ns(s->update_timer)) {
>but I would like to have a testcase for it in tests/rtc-test.c.

>Can you check if the above works and try writing a testcase (that fails 
>without the patch and succeeds with it)?
>Thanks,
I don't  think it can works. REG_C_UF is totally cleared by periodic timer in original code.

after periodic timer stoped, the REG_C_UF  is never cleared.

rtc_update_timer has cleared REG_A_UIP,I think  the patch  does nothing.

I reproduce the bug when many windows VMs reboot and it is about the method of  windows kernel accessing rtc .

so i don't know how to write the testcase.




>Paolo

Re: [Qemu-devel] [PATCH V3] rtc: fix a infinite loop in windows vmstartup

[Paolo Bonzini]

On 25/07/2017 11:29, peng.hao2@zte.com.cn wrote:
>>On 25/07/2017 06:14, peng.hao2@zte.com.cn wrote:
> 
>>>> On 24/07/2017 20:35, Peng Hao wrote:
>>> 
>>> 
>>> 
>>> 
>>> 
>>>>> When a windows vm starts, periodic timer of rtc will stop several times.
>>>>> windows kernel will check whether REG_A_UIP is changed. REG_C's interrupt
>>>>> flags will not be cleared when periodic timer stops and the update timer
>>>>> will switch to alarm timer. So the expiration time of alarm timer is very
>>>>> long and REG_A_UIP will not vary.At last windows kernel will repeat to 
>>>>> check REG_A_UIP all the time.
>>> 
>>>> This should not happen.  REG_A_UIP is set and cleared in register A
>>>> every second, like this:
>>>>        case RTC_REG_A:
>>>>            if (update_in_progress(s)) {
>>>>                s->cmos_data[s->cmos_index] |= REG_A_UIP
>>>>            } else {
>>>>                s->cmos_data[s->cmos_index] &= ~REG_A_UIP
>>>>            }
>>>>            ret = s->cmos_data[s->cmos_index]
>>>>            break
>>> 
>>> 
>>> 
>>> when periodic timer stop, update timer is set to a long expire time (as alarm timer).
> 
>>I think I see the bug now:
> 
>>diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c
>>index 1b8d3d7d4c..6184b4378e 100644
>>--- a/hw/timer/mc146818rtc.c
>>+++ b/hw/timer/mc146818rtc.c
>>@@ -321,9 +321,11 @@ static void check_update_timer(RTCState *s)
>>     s->next_alarm_time = next_update_time +
>>                          (next_alarm_sec - 1) * NANOSECONDS_PER_SECOND;
>> 
>>-    if (s->cmos_data[RTC_REG_C] & REG_C_UF) {
>>-        /* UF is set, but AF is clear.  Program the timer to target
>>-         * the alarm time.  */
>>+    if ((s->cmos_data[RTC_REG_C] & REG_C_UF) &&
>>+        !(s->cmos_data[RTC_REG_A] & REG_A_UIP)) {
>>+        /* If UIP was latched, we need to clear it at the next update.
>>+         * Otherwise, if UF is set we only need to program the timer to
>>+         * target the alarm time.  */
>>         next_update_time = s->next_alarm_time;
>>     }
>>     if (next_update_time != timer_expire_time_ns(s->update_timer)) {
>>
>>but I would like to have a testcase for it in tests/rtc-test.c.
>>Can you check if the above works and try writing a testcase (that fails 
>>without the patch and succeeds with it)?
>>Thanks,
> 
> I don't  think it can works.

Have you tested it?

> REG_C_UF is totally cleared by periodic timer in original code.
> after periodic timer stoped, the REG_C_UF  is never cleared.

Your patch cleared REG_C_UF, but you have not said why the actual
hardware would clear REG_C_UF (it wouldn't).

> rtc_update_timer has cleared REG_A_UIP,I think  the patch  does nothing.
> 
> I reproduce the bug when many windows VMs reboot and it is about the
> method of  windows kernel accessing rtc .
> 
> so i don't know how to write the testcase.

First of all you have to describe the exact sequence of register
accesses that causes the problem.  I can help you writing the testcase,
but your changes to the device model must reflect the actual behavior of
the hardware.

Paolo