Re: EFI image - SAL_DESC_PLATFORM_FEATURE bits

[Tristan Gingold <tgingold@xxxxxxx>]

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