Skip to contentSkip to conversation

EFI mode after running kexec

DISCUSSION Greg KH 5 participants 10 messages Aug 29, 2013 – Aug 31, 2013 7 messages not in the archive EFI

lore
Share & tools
lore

Greg KH

author
#0 lore raw

Hi all,

I've been messing with UEFI booting a kernel and then later on, using kexec to boot another kernel, and noticed that the kexec'ed kernel is not really in EFI mode, although the EFI framebuffer seems present and able to be used.

Is this to be expected? I'd think that the EFI framebuffer wouldn't be around anymore. Odds are this is a BIOS bug, given that the machine I'm using is a really old UEFI mode (i.e. before secure boot mode ever showed up), but should it work this way?

And, to get kexec to run the kernel in EFI mode, would require kexec to treat the kernel as a EFI binary and run it that way, instead of the "normal" way it currently is, right?

thanks,

greg k-h

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw
Quoted 11 lines · Greg KH

Hi all,

I've been messing with UEFI booting a kernel and then later on, using kexec to boot another kernel, and noticed that the kexec'ed kernel is not really in EFI mode, although the EFI framebuffer seems present and able to be used.

Is this to be expected? I'd think that the EFI framebuffer wouldn't be around anymore. Odds are this is a BIOS bug, given that the machine I'm using is a really old UEFI mode (i.e. before secure boot mode ever showed up), but should it work this way?

AFAIK, it's to be expected at this point. kexec doesn't work as it should with UEFI. I believe Matthew and/or Matt can elaborate further, but it has to do with only being able to call ExitBootServices once and providing mappings to the UEFI Runtime services functions.

Quoted 3 lines

And, to get kexec to run the kernel in EFI mode, would require kexec to treat the kernel as a EFI binary and run it that way, instead of the "normal" way it currently is, right?

I think so.

josh

A message that is not in the archive (sent off-list or not yet received): CA+5PVA7jec5DAxgKachkBw1VFobz4rVMQwcqzYQ7ynk7=+d+zg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org

#4 lore raw
Quoted 13 lines · Josh Boyer
Quoted 11 lines · Greg KH

Hi all,

I've been messing with UEFI booting a kernel and then later on, using kexec to boot another kernel, and noticed that the kexec'ed kernel is not really in EFI mode, although the EFI framebuffer seems present and able to be used.

Is this to be expected? I'd think that the EFI framebuffer wouldn't be around anymore. Odds are this is a BIOS bug, given that the machine I'm using is a really old UEFI mode (i.e. before secure boot mode ever showed up), but should it work this way?

Quoted 5 lines

AFAIK, it's to be expected at this point. kexec doesn't work as it should with UEFI. I believe Matthew and/or Matt can elaborate further, but it has to do with only being able to call ExitBootServices once and providing mappings to the UEFI Runtime services functions.

There's also the SetVirtualAddressMap() problem ...

Quoted 5 lines
Quoted 3 lines

And, to get kexec to run the kernel in EFI mode, would require kexec to treat the kernel as a EFI binary and run it that way, instead of the "normal" way it currently is, right?

I think so.

There are two ways we boot a kernel in EFI mode: one is with BootServices intact (because the bootloader didn't call ExitBootServices()) which is becoming more common and the other with only RunTime Services. The best that can be hoped for in kexec is the latter, since it's practically impossible to reinitialise the BootServices once they've been trashed.

James

author
#5 lore raw
Quoted 14 lines · James Bottomley
Quoted 13 lines · Josh Boyer
Quoted 11 lines · Greg KH

Hi all,

I've been messing with UEFI booting a kernel and then later on, using kexec to boot another kernel, and noticed that the kexec'ed kernel is not really in EFI mode, although the EFI framebuffer seems present and able to be used.

Is this to be expected? I'd think that the EFI framebuffer wouldn't be around anymore. Odds are this is a BIOS bug, given that the machine I'm using is a really old UEFI mode (i.e. before secure boot mode ever showed up), but should it work this way?

Quoted 7 lines
Quoted 5 lines

AFAIK, it's to be expected at this point. kexec doesn't work as it should with UEFI. I believe Matthew and/or Matt can elaborate further, but it has to do with only being able to call ExitBootServices once and providing mappings to the UEFI Runtime services functions.

There's also the SetVirtualAddressMap() problem ...

Ugh, that would be a real mess...

Quoted 4 lines
Quoted 4 lines
Quoted 3 lines

And, to get kexec to run the kernel in EFI mode, would require kexec to treat the kernel as a EFI binary and run it that way, instead of the "normal" way it currently is, right?

Quoted 8 lines
Quoted 1 line

I think so.

There are two ways we boot a kernel in EFI mode: one is with BootServices intact (because the bootloader didn't call ExitBootServices()) which is becoming more common and the other with only RunTime Services. The best that can be hoped for in kexec is the latter, since it's practically impossible to reinitialise the BootServices once they've been trashed.

So that would take some kexec work. I'm currently working on xen support in kexec, I'll add this to my "TODO" list for after that gets done.

thanks,

greg k-h

A message that is not in the archive (sent off-list or not yet received): [email protected]

#7 lore raw
Quoted 5 lines · Greg KH
Quoted 2 lines

There's also the SetVirtualAddressMap() problem ...

Ugh, that would be a real mess...

I and Borislav actually came up with a reasonable solution for SVAM(). It sadly creates a new ABI, but at least is (a) reasonable and (b) seems to match Windows close enough. Basically the regions should get mapped one by one from -4 GB downwards.

-hpa

A message that is not in the archive (sent off-list or not yet received): [email protected]

#9 lore raw
Quoted 4 lines · H. Peter Anvin

I and Borislav actually came up with a reasonable solution for SVAM(). It sadly creates a new ABI, but at least is (a) reasonable and (b) seems to match Windows close enough. Basically the regions should get mapped one by one from -4 GB downwards.

Yep, and the mapping works both on OVMF and on my baremetal box. I'm currently on vacation but will send out the final stuff when I get back.

Teaching the kexec-ed kernel to simply use those mappings *without* doing SVAM() should be easy afterwards.

Thanks.

Signature · 2 lines
Regards/Gruss,
Boris.

A message that is not in the archive (sent off-list or not yet received): 20130831045244.GA12617-W2mmg7yuTz0QF/[email protected]

author
#11 lore raw
Quoted 11 lines · Borislav Petkov
Quoted 4 lines · H. Peter Anvin

I and Borislav actually came up with a reasonable solution for SVAM(). It sadly creates a new ABI, but at least is (a) reasonable and (b) seems to match Windows close enough. Basically the regions should get mapped one by one from -4 GB downwards.

Yep, and the mapping works both on OVMF and on my baremetal box. I'm currently on vacation but will send out the final stuff when I get back.

Teaching the kexec-ed kernel to simply use those mappings *without* doing SVAM() should be easy afterwards.

Ah, that sounds great, if you need me to test anything, just let me know, I have some UEFI test boxes I've been working on here...

thanks,

greg k-h

author
#12 lore raw
In reply to a message not in the archive
Quoted 8 lines · Josh Boyer
Quoted 7 lines · Greg KH

Hi all,

I've been messing with UEFI booting a kernel and then later on, using kexec to boot another kernel, and noticed that the kexec'ed kernel is not really in EFI mode, although the EFI framebuffer seems present and able to be used.

Quoted 7 lines
Quoted 4 lines

Is this to be expected? I'd think that the EFI framebuffer wouldn't be around anymore. Odds are this is a BIOS bug, given that the machine I'm using is a really old UEFI mode (i.e. before secure boot mode ever showed up), but should it work this way?

AFAIK, it's to be expected at this point. kexec doesn't work as it should with UEFI.

How "should" it work? It seems to boot a kernel just fine, although not in EFI mode, which makes sense (I had forgotten about the BootServices stuff.)

Quoted 3 lines

I believe Matthew and/or Matt can elaborate further, but it has to do with only being able to call ExitBootServices once and providing mappings to the UEFI Runtime services functions.

That makes sense.

thanks,

greg k-h

A message that is not in the archive (sent off-list or not yet received): [email protected]

#14 lore raw
Quoted 14 lines · Greg KH
Quoted 13 lines · Josh Boyer
Quoted 11 lines · Greg KH

Hi all,

I've been messing with UEFI booting a kernel and then later on, using kexec to boot another kernel, and noticed that the kexec'ed kernel is not really in EFI mode, although the EFI framebuffer seems present and able to be used.

Is this to be expected? I'd think that the EFI framebuffer wouldn't be around anymore. Odds are this is a BIOS bug, given that the machine I'm using is a really old UEFI mode (i.e. before secure boot mode ever showed up), but should it work this way?

Quoted 6 lines
Quoted 2 lines

AFAIK, it's to be expected at this point. kexec doesn't work as it should with UEFI.

How "should" it work? It seems to boot a kernel just fine, although not in EFI mode, which makes sense (I had forgotten about the BootServices stuff.)

Right, well in my ideal world if you kexec a kernel on a UEFI machine, the resulting kernel is up and running as the previous kernel was. Which is to say, it's in UEFI mode.

Maybe that's more hassle than it's worth but that was what I was thinking when I said "should". It may be possible to use a kexec'd kernel as it boots today on these machines. I believe the current line of thought from the kdump people is that kdump kernels could operate in this mode, for example. That's a short-lived uptime and scoped usecase though.

josh

A message that is not in the archive (sent off-list or not yet received): CA+5PVA5PHc4vOcWwCgTHS=CP8oei-Jc5GK2dfi=EdD_wGVZpXQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org

author
#16 lore raw
Quoted 18 lines · Josh Boyer
Quoted 17 lines · Greg KH
Quoted 15 lines · Josh Boyer
Quoted 11 lines · Greg KH

Hi all,

I've been messing with UEFI booting a kernel and then later on, using kexec to boot another kernel, and noticed that the kexec'ed kernel is not really in EFI mode, although the EFI framebuffer seems present and able to be used.

Is this to be expected? I'd think that the EFI framebuffer wouldn't be around anymore. Odds are this is a BIOS bug, given that the machine I'm using is a really old UEFI mode (i.e. before secure boot mode ever showed up), but should it work this way?

AFAIK, it's to be expected at this point. kexec doesn't work as it should with UEFI.

Quoted 7 lines
Quoted 3 lines

How "should" it work? It seems to boot a kernel just fine, although not in EFI mode, which makes sense (I had forgotten about the BootServices stuff.)

Right, well in my ideal world if you kexec a kernel on a UEFI machine, the resulting kernel is up and running as the previous kernel was. Which is to say, it's in UEFI mode.

I agree, that would be ideal.

Quoted 6 lines

Maybe that's more hassle than it's worth but that was what I was thinking when I said "should". It may be possible to use a kexec'd kernel as it boots today on these machines. I believe the current line of thought from the kdump people is that kdump kernels could operate in this mode, for example. That's a short-lived uptime and scoped usecase though.

For kdump, yes, but other people use kexec for "real" kernels. Some people use kexec as the bootloader itself, as that's the only way to boot Linux on a platform, so they are not always short-lived at all.

thanks,

greg k-h