This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] [PATCH] Move RTC from Qemu to HV

To: "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] Move RTC from Qemu to HV
From: "Li, Xin B" <xin.b.li@xxxxxxxxx>
Date: Fri, 29 Sep 2006 13:43:05 +0800
Cc: "Mallick, Asit K" <asit.k.mallick@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Delivery-date: Thu, 28 Sep 2006 22:44:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbhfSgZ1zf5Dd22R7mr0rlT/3BpdwAA4+OPACIANVAAAopMNgA83y+AACC9oRA=
Thread-topic: [Xen-devel] [PATCH] Move RTC from Qemu to HV
Keir, how about using the attached patch as workaround for xen 3.0.3.
With it 64 bit win2003 UP and SMP can work fine, 64bit SMP can go hct stress 
for 20 hours.

Signed-off-by: Xin Li <xin.b.li@xxxxxxxxx>
Signed-off-by: Eddie Dong <eddie.dong@xxxxxxxxx>


>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
>Yang, Xiaowei
>Sent: 2006年9月28日 22:03
>To: Keir Fraser
>Cc: Mallick, Asit K; xen-devel@xxxxxxxxxxxxxxxxxxx; Nakajima, Jun
>Subject: RE: [Xen-devel] [PATCH] Move RTC from Qemu to HV
>>Xen has a view of UTC, kept up to date by domain0. There is also
>>already to set a per-domain offset from UTC 
>>Xen is quite capable of setting all time fields itself.
>>As for the rest of the CMOS fields, I believe that they only contain
>>basic info like boot order? This is only derived by qemu from
>>switches -- we could make xend push down initialiser values instead.
>>only pushing implementation of time-related CMOS bytes[*] to 
>Xen in the
>>first instance does make sense though...
>>[*] That's more than 10 bytes though, right? There are status and
>>registers at indexes 0xa-0xd?
>This is the revised patch, which adopts your suggestion to handle CMOS
>ram. No CMOS data in the shared io page any more. RTC in HV maintains
>the first 14 (10 is a typo:) time/interrupt related bytes. Initial CMOS
>date equals to Xen wallclock + time_offset_seconds. Qemu handles the
>rest CMOS ram. 
>The patch also considers SVM guest. For Ia64 part, as it has no problem
>as x86, the patch doesn't affect it.

Attachment: win2003_halt_workaround_for_xen_3.0.3.patch
Description: win2003_halt_workaround_for_xen_3.0.3.patch

Xen-devel mailing list