[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] Move RTC from Qemu to HV
- To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
- 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=
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
Hi,
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.
-b
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
