On Tue, Jan 27, 2009 at 04:44:29PM +0100, Jes Sorensen wrote: > Hi Tristan, > > I have a problem with the EFI image under KVM (well it would be relevant > under Xen too). > > Basically our system has the ITC_drift bit set in the > SAL_DESC_PLATFORM_FEATURE entry in the SAL table, due to the fact that > the ITC isn't synchronized throughout the system. Ah yes, sn2! > However looking at how Linux picks this up, I realize that this > information is propagated through the SAL sys_entry table rather than > through a SAL call, which would have been dead easy to emulate. > > So my question is how your EFI image builds the sys_entry table? Is it > possible for KVM/Xen etc. to pass down information that the system clock > drifts or does it need to be hardcoded in the image? If the latter, do > you have any pointers to how one goes about rebuilding the image? The SAL system table is built in edk2-sparse/EdkXenPkg/Dxe/XenSal/XenSal.c. There is currently no platform features entry but it is easy to add one. I suppose this entry can be populated by using an hypercall. There is a README that explains how to build the firmware - it's tedious. > Right now I have a particularly bad setup where my test system has CPUs > of different clock speeds, plus the ITC isn't stable, so the time seen > by my guest kernels bounces left right and center depending on which > physical CPU it is running on at a given moment :-( > > Linux is capable of handling drifting ITCs already, so I don't think it > would be a problem for us to hardcode this bit. No idea whether or not > Windows even looks at it? I don't know. Tristan. > > Cheers, > Jes -- To unsubscribe from this list: send the line "unsubscribe kvm-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
