Hello Feng,
Can you educate me about your commit 772be899bc, "86: Make EFI RTC
function depend on 32bit again"?
It adds "#ifdef CONFIG_X86_32" to avoid using efi_get_time() and
efi_set_rtc_mmss(), but there's no explanation of *why* those services
only work on 32-bit.
Is this an EFI spec limitation? Do the other EFI runtime services
work on 64-bit, since you didn't touch them? Or do we just not use
any of the others?
Is this something that can be fixed, so we *could* use efi_get_time()
on 64-bit if we did some work? What would need to be done?
Bjorn
Hi Bjorn,
On Sat, 31 Jul 2010 04:58:48 +0800
Bjorn Helgaas <[email protected]> wrote:
> Hello Feng,
>
> Can you educate me about your commit 772be899bc, "86: Make EFI RTC
> function depend on 32bit again"?
>
> It adds "#ifdef CONFIG_X86_32" to avoid using efi_get_time() and
> efi_set_rtc_mmss(), but there's no explanation of *why* those services
> only work on 32-bit.
>
> Is this an EFI spec limitation? Do the other EFI runtime services
> work on 64-bit, since you didn't touch them? Or do we just not use
> any of the others?
>
Commit 772be899bc, "86: Make EFI RTC function depend on 32bit again" is
a regression fix for 7bd867d "x86: Move get/set_wallclock to x86_platform_ops".
These 2 commits just abstract the rtc service for legacy x86 PC/EFI/Virtualiation
kernel, and has no functional change to existing code.
I'm not familiar with EFI, but my understanding is current EFI code in
kernel only provides the get/set_time service for x86_32 platform.
Cc Ying who is more familiar with EFI than me.
Thanks,
Feng
Hi, Bjorn,
On Mon, 2010-08-02 at 10:35 +0800, Tang, Feng wrote:
> Hi Bjorn,
>
> On Sat, 31 Jul 2010 04:58:48 +0800
> Bjorn Helgaas <[email protected]> wrote:
>
> > Hello Feng,
> >
> > Can you educate me about your commit 772be899bc, "86: Make EFI RTC
> > function depend on 32bit again"?
> >
> > It adds "#ifdef CONFIG_X86_32" to avoid using efi_get_time() and
> > efi_set_rtc_mmss(), but there's no explanation of *why* those services
> > only work on 32-bit.
> >
> > Is this an EFI spec limitation? Do the other EFI runtime services
> > work on 64-bit, since you didn't touch them? Or do we just not use
> > any of the others?
> >
>
> Commit 772be899bc, "86: Make EFI RTC function depend on 32bit again" is
> a regression fix for 7bd867d "x86: Move get/set_wallclock to x86_platform_ops".
> These 2 commits just abstract the rtc service for legacy x86 PC/EFI/Virtualiation
> kernel, and has no functional change to existing code.
>
> I'm not familiar with EFI, but my understanding is current EFI code in
> kernel only provides the get/set_time service for x86_32 platform.
I think get/set_time service should have worked on x86_64 too. Just
lacks proper debugging/testing for recent kernels.
Best Regards,
Huang Ying
Huang Ying <[email protected]> writes:
> Hi, Bjorn,
>
> On Mon, 2010-08-02 at 10:35 +0800, Tang, Feng wrote:
>> Hi Bjorn,
>>
>> On Sat, 31 Jul 2010 04:58:48 +0800
>> Bjorn Helgaas <[email protected]> wrote:
>>
>> > Hello Feng,
>> >
>> > Can you educate me about your commit 772be899bc, "86: Make EFI RTC
>> > function depend on 32bit again"?
>> >
>> > It adds "#ifdef CONFIG_X86_32" to avoid using efi_get_time() and
>> > efi_set_rtc_mmss(), but there's no explanation of *why* those services
>> > only work on 32-bit.
>> >
>> > Is this an EFI spec limitation? Do the other EFI runtime services
>> > work on 64-bit, since you didn't touch them? Or do we just not use
>> > any of the others?
>> >
>>
>> Commit 772be899bc, "86: Make EFI RTC function depend on 32bit again" is
>> a regression fix for 7bd867d "x86: Move get/set_wallclock to x86_platform_ops".
>> These 2 commits just abstract the rtc service for legacy x86 PC/EFI/Virtualiation
>> kernel, and has no functional change to existing code.
>>
>> I'm not familiar with EFI, but my understanding is current EFI code in
>> kernel only provides the get/set_time service for x86_32 platform.
>
> I think get/set_time service should have worked on x86_64 too. Just
> lacks proper debugging/testing for recent kernels.
Is there any reason we just don't rip those calls out?
If we don't need them and we lack proper debug/testing I don't see the point
of using the EFI calls and exposing ourselves to more potential BIOS breakage.
EFI runtime calls have the nasty fact that they don't work in general even
if EFI is present because you may have the wrong word size EFI running on
your machine. A 32bit EFI and a 64bit kernel or a 64bit EFI and a 32bit kernel.
Eric
On Tue, Aug 03, 2010 at 02:45:33PM -0700, Eric W. Biederman wrote:
> EFI runtime calls have the nasty fact that they don't work in general even
> if EFI is present because you may have the wrong word size EFI running on
> your machine. A 32bit EFI and a 64bit kernel or a 64bit EFI and a 32bit kernel.
You've already failed to boot in that case.
--
Matthew Garrett | [email protected]
Matthew Garrett <[email protected]> writes:
> On Tue, Aug 03, 2010 at 02:45:33PM -0700, Eric W. Biederman wrote:
>
>> EFI runtime calls have the nasty fact that they don't work in general even
>> if EFI is present because you may have the wrong word size EFI running on
>> your machine. A 32bit EFI and a 64bit kernel or a 64bit EFI and a 32bit kernel.
>
> You've already failed to boot in that case.
Only if you have EFI runtime services enabled in your kernel. You can
skip the efi junk and the kernel runs just fine. Doing what we do on
every other platform which appears to be a combination of ACPI and
direct hardware access appears to be good enough, and that is a path
that actually gets tested regularly.
Eric
On Tue, Aug 03, 2010 at 02:58:10PM -0700, Eric W. Biederman wrote:
> Only if you have EFI runtime services enabled in your kernel. You can
> skip the efi junk and the kernel runs just fine. Doing what we do on
> every other platform which appears to be a combination of ACPI and
> direct hardware access appears to be good enough, and that is a path
> that actually gets tested regularly.
I think wanting to set the nvram variables so that your bootloader works
is a pretty typical usecase...
--
Matthew Garrett | [email protected]