[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Move RTC from Qemu to HV
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 On 26/9/06 16:05, "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx> wrote: > As we know some version of Windows (e.g 32bit Vista and 64bit Win2k3) > use RTC as main periodic timer at 64HZ. Currently RTC is in Qemu which > means its irq may be potentially lost due to Qemu not got scheduled on > time. And it's not sync with Guest TSC (adjusted by TSC_OFFSET). This > will cause many problems, like HVM time goes slow; TSC can't be measured > by cross referring to RTC time. > This patch moves RTC from Qemu to HV, to resolve these problems. Since > we still need Qemu to fill out RTC ram with (local)time, fd/hd > information, HV will copy this ram from Qemu at startup and then > maintains it by itself. > Another issue resolved by this patch is Windows which use RTC as > periodic timer hangs at login screen because there are no resources to > wait it up after it calls halt. After moving, RTC timer will wake it. > One extra benefit is that Vista responses faster. It can be explained by > fewer IO port access cost and more accurate RTC time, which Vista may > use to refresh screen. > > Thanks, > Xiaowei > > > _______________________________________________ > 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |