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: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Move RTC from Qemu to HV
From: "B Thomas" <bjthomas3@xxxxxxxxx>
Date: Wed, 27 Sep 2006 08:01:58 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>
Delivery-date: Wed, 27 Sep 2006 05:02:29 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=PbEHfdb5omGpaHehLABuar+6+16iykiZ5zX35u2eFEo0yyu7LXSClZ8yylZm6OMt4HDxfcBgjiFI1mIk0Oq2pV8rcu8eBi4OrAV2DXugQ8Z5RIqIIE55NAgCC2BGqxxcPK6JGxSDZO8gzzYvbcDGfc3rTSSG7rZ36zhbyLz/Ffg=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C13FFB67.1B06%Keir.Fraser@xxxxxxxxxxxx>
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>
References: <8C834404208B254EAD4E532C94859869056AAD@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C13FFB67.1B06%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

Wherever this discussion ends up taking the implementation, it would be nice if the CMOS time values were accessible from any domain 0 control plane software.  Keir has pointed out one use, setting a per-domain UTC offset.  A related use is to also be able to detect when a user domain has changed these values (eg, hwclock -w). This yields the ability to add persistence to the offset from the control software.

The original timeoffset patch to qemu allowed for this (setting, change detection and retrieval). For the purposes of this reply, the details of the implementation matter less than the capability.


On 9/27/06, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:
On 27/9/06 09:16, "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx> wrote:

> Lastly, as for CMOS ram initialization, we have an alternative: Only
> move the first 10 bytes of time/interrupt related CMOS ram out of 128
> from Qemu to HV while still leaving the left in Qemu. Unfortunately how
> to initialize time is still a little tricky: as we still need configure
> option (like localtime) to fill in the space, it may be passed by
> xc_set_hvm_param (like for option apic) at startup.
> What do you think of it?

Xen has a view of UTC, kept up to date by domain0. There is also facility
already to set a per-domain offset from UTC (XEN_DOMCTL_settimeoffset). So
Xen is quite capable of setting all time fields itself.

As for the rest of the CMOS fields, I believe that they only contain some
basic info like boot order? This is only derived by qemu from command-line
switches -- we could make xend push down initialiser values instead. Maybe
only pushing implementation of time-related CMOS bytes[*] to Xen in the
first instance does make sense though...

-- Keir

[*] That's more than 10 bytes though, right? There are status and control
registers at indexes 0xa-0xd?

Xen-devel mailing list

Xen-devel mailing list