[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 27 Sep 2006 09:56:55 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 27 Sep 2006 01:55:51 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcbhfSgZ1zf5Dd22R7mr0rlT/3BpdwAA4+OPACIANVAAAopMNg==
  • Thread-topic: [Xen-devel] [PATCH] Move RTC from Qemu to HV

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.