EFI image - SAL_DESC_PLATFORM_FEATURE bits

EFI image - SAL_DESC_PLATFORM_FEATURE bits

[Jes Sorensen]

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.

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?

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?

Cheers,
Jes

Re: EFI image - SAL_DESC_PLATFORM_FEATURE bits

[Tristan Gingold]

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

Re: EFI image - SAL_DESC_PLATFORM_FEATURE bits

[Jes Sorensen]

Tristan Gingold wrote:
> On Tue, Jan 27, 2009 at 04:44:29PM +0100, Jes Sorensen wrote:
>> 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.

Hi Tristan,

Thanks for the info - where do I find the firmware? Is it in the Xen
hg repositories?

I was hoping it would be a walk in the park to build, but I kinda feared
you would say that. Do I need a special environment to build it, like a
special pre-historic version of GCC running on RHEL 3 or something like
that?

Cheers,
Jes

Re: EFI image - SAL_DESC_PLATFORM_FEATURE bits

[Tristan Gingold]

On Wed, Jan 28, 2009 at 10:50:41AM +0100, Jes Sorensen wrote:
> Hi Tristan,
>
> Thanks for the info - where do I find the firmware? Is it in the Xen
> hg repositories?

Yes,
xenbits.xensource.com/efi-vfirmware.hg


> I was hoping it would be a walk in the park to build, but I kinda feared
> you would say that. Do I need a special environment to build it, like a
> special pre-historic version of GCC running on RHEL 3 or something like
> that?
Worse: you need a java environment.
Recent versions of TianoCore uses python (which must be much easier to build)
but I haven't time to update.

Tristan.

>
> Cheers,
> Jes

Re: EFI image - SAL_DESC_PLATFORM_FEATURE bits

[Jes Sorensen]

Tristan Gingold wrote:
> On Wed, Jan 28, 2009 at 10:50:41AM +0100, Jes Sorensen wrote:
>> Hi Tristan,
>>
>> Thanks for the info - where do I find the firmware? Is it in the Xen
>> hg repositories?
> 
> Yes,
> xenbits.xensource.com/efi-vfirmware.hg

[jes@leavenworth lw]$ hg clone http://xenbits.xensource.com/efi-vfirmware.hg
requesting all changes
abort: HTTP Error 404: Not Found
[jes@leavenworth lw]$

Is this the correct address? It's been ages since I used mercurial, so
maybe I have gone a little rusty.

> 
>> I was hoping it would be a walk in the park to build, but I kinda feared
>> you would say that. Do I need a special environment to build it, like a
>> special pre-historic version of GCC running on RHEL 3 or something like
>> that?
> Worse: you need a java environment.
> Recent versions of TianoCore uses python (which must be much easier to build)
> but I haven't time to update.

Gosh, you really know how to make my day :-( I have a feeling I am going
to regret getting into this :-)

Thanks,
Jes

Re: EFI image - SAL_DESC_PLATFORM_FEATURE bits

[Tristan Gingold]

On Wed, Jan 28, 2009 at 11:22:34AM +0100, Jes Sorensen wrote:
> Tristan Gingold wrote:
>> On Wed, Jan 28, 2009 at 10:50:41AM +0100, Jes Sorensen wrote:
>>> Hi Tristan,
>>>
>>> Thanks for the info - where do I find the firmware? Is it in the Xen
>>> hg repositories?
>>
>> Yes,
>> xenbits.xensource.com/efi-vfirmware.hg
>
> [jes@leavenworth lw]$ hg clone http://xenbits.xensource.com/efi-vfirmware.hg
> requesting all changes
> abort: HTTP Error 404: Not Found
> [jes@leavenworth lw]$
>
> Is this the correct address? It's been ages since I used mercurial, so
> maybe I have gone a little rusty.
 
Humm, you're right.  Try:
http://xenbits.xen.org/ext/efi-vfirmware.hg

>>> I was hoping it would be a walk in the park to build, but I kinda feared
>>> you would say that. Do I need a special environment to build it, like a
>>> special pre-historic version of GCC running on RHEL 3 or something like
>>> that?
>> Worse: you need a java environment.
>> Recent versions of TianoCore uses python (which must be much easier to build)
>> but I haven't time to update.
>
> Gosh, you really know how to make my day :-( I have a feeling I am going
> to regret getting into this :-)

Sorry :-)

Tristan.

Re: EFI image - SAL_DESC_PLATFORM_FEATURE bits

[Jes Sorensen]

Hi Tristan,

One more question, binutils and gcc? Do you use special versions or
the default ones provided by your distro?

I tried to follow the guidelines in edk2 and build gcc-4.1.0 and
binutils according to how they do it, but both complain that the
target ia64-tiano-pe does not exist.....

any pointers?

Thanks,
Jes