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

["Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>]

>
>This is *definitely* the way to go, but we won't apply a patch of this
size
>until development reopens for 3.0.4. We want to focus on 3.0.3
stabilisation
>for the next week or two.
>
>Also it'd be nice to not have any RTC/CMOS code built into the device
model
>at all. Really all the initial state could be filled out from xend, and
that
>would be cleaner. A patch which puts CMOS data in the shared io page
isn't
>going to get checked in. :-)
>
Keir,
I understand your concern about the stability of 3.0.3. Let me explain
more:)

Firstly this patch is not as big as it looks like. Almost half of it is
ported from original Qemu RTC code. I think we can trust this code base.

Secondly, the patch itself is rather stable. After tested on our local
testing system, it passes all 32 tests, which consists of all basic VMs
combination (VMX Winxp sp1/sp2, 2.4/2.6 Linux and PV). Pls. refer to the
attached log for details. 32bit Win2k/Vista and 64bit Win2k3 are also
verified workable.

Thirdly, this patch really resolves some apparent issues:
- Windows time, which use RTC as periodic interrupt (e.g. Vista) goes
slow.
- 32/64bit Win2k3 hangs.
- Vista updates screen slow.
And some potential bug, like calibrating TSC by cross referring to RTC
time.

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?

Thanks,
Xiaowei

Attachment: Patch_Test_Report Testing Finished.txt
Description: Patch_Test_Report Testing Finished.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel