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@lists.xensource.com http://lists.xensource.com/xen-devel
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@intel.com> 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@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> >This is *definitely* the way to go, but we won''t apply a patch of thissize>until development reopens for 3.0.4. We want to focus on 3.0.3stabilisation>for the next week or two. > >Also it''d be nice to not have any RTC/CMOS code built into the devicemodel>at all. Really all the initial state could be filled out from xend, andthat>would be cleaner. A patch which puts CMOS data in the shared io pageisn''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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 27/9/06 09:16, "Yang, Xiaowei" <xiaowei.yang@intel.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
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@cl.cam.ac.uk> wrote:> > On 27/9/06 09:16, "Yang, Xiaowei" <xiaowei.yang@intel.com> 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@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>Xen has a view of UTC, kept up to date by domain0. There is alsofacility>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 containsome>basic info like boot order? This is only derived by qemu fromcommand-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... > >[*] That''s more than 10 bytes though, right? There are status andcontrol>registers at indexes 0xa-0xd?Keir, This is the revised patch, which adopts your suggestion to handle CMOS ram. No CMOS data in the shared io page any more. RTC in HV maintains the first 14 (10 is a typo:) time/interrupt related bytes. Initial CMOS date equals to Xen wallclock + time_offset_seconds. Qemu handles the rest CMOS ram. The patch also considers SVM guest. For Ia64 part, as it has no problem as x86, the patch doesn''t affect it. Thanks, Xiaowei _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir, how about using the attached patch as workaround for xen 3.0.3. With it 64 bit win2003 UP and SMP can work fine, 64bit SMP can go hct stress for 20 hours. Signed-off-by: Xin Li <xin.b.li@intel.com> Signed-off-by: Eddie Dong <eddie.dong@intel.com> thanks -Xin>-----Original Message----- >From: xen-devel-bounces@lists.xensource.com >[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of >Yang, Xiaowei >Sent: 2006年9月28日 22:03 >To: Keir Fraser >Cc: Mallick, Asit K; xen-devel@lists.xensource.com; Nakajima, Jun >Subject: RE: [Xen-devel] [PATCH] Move RTC from Qemu to HV > >>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... >> >>[*] That''s more than 10 bytes though, right? There are status and >control >>registers at indexes 0xa-0xd? > > >Keir, >This is the revised patch, which adopts your suggestion to handle CMOS >ram. No CMOS data in the shared io page any more. RTC in HV maintains >the first 14 (10 is a typo:) time/interrupt related bytes. Initial CMOS >date equals to Xen wallclock + time_offset_seconds. Qemu handles the >rest CMOS ram. > >The patch also considers SVM guest. For Ia64 part, as it has no problem >as x86, the patch doesn''t affect it. > >Thanks, >Xiaowei >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/9/06 6:43 am, "Li, Xin B" <xin.b.li@intel.com> wrote:> Keir, how about using the attached patch as workaround for xen 3.0.3. > With it 64 bit win2003 UP and SMP can work fine, 64bit SMP can go hct stress > for 20 hours. > > Signed-off-by: Xin Li <xin.b.li@intel.com> > Signed-off-by: Eddie Dong <eddie.dong@intel.com>Rotfl. No. HVM guests would sleep no longer than 16us! We''ll get the proper patch in asap. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> >On 29/9/06 6:43 am, "Li, Xin B" <xin.b.li@intel.com> wrote: > >> Keir, how about using the attached patch as workaround for xen 3.0.3. >> With it 64 bit win2003 UP and SMP can work fine, 64bit SMP >can go hct stress >> for 20 hours. >> >> Signed-off-by: Xin Li <xin.b.li@intel.com> >> Signed-off-by: Eddie Dong <eddie.dong@intel.com> > >Rotfl. No. HVM guests would sleep no longer than 16us!It''s 16ms, since ACPI windows usually use 64Hz RTC timer. -Xin> >We''ll get the proper patch in asap. > > -- Keir >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> On 29/9/06 6:43 am, "Li, Xin B" <xin.b.li@intel.com> wrote: > >> Keir, how about using the attached patch as workaround for xen 3.0.3. >> With it 64 bit win2003 UP and SMP can work fine, 64bit SMP can go >> hct stress for 20 hours. >> >> Signed-off-by: Xin Li <xin.b.li@intel.com> >> Signed-off-by: Eddie Dong <eddie.dong@intel.com> > > Rotfl. No. HVM guests would sleep no longer than 16us! > > We''ll get the proper patch in asap. > > -- Keir >Keir: The proper patch is either to move RTC into hypervisor or modify DM IRQ injection mechanism. I''d prefer to take the prior solution while your concern is righ too as we are in RC1 now and want this size of patch. For the later one, the change is much tricky and it may introduce some regression issue and big imapct to other architecture like IA-64. So, what is your tradeoff now? We must fix this kind of bug, right? Thx, Eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel