Re: [Xen-devel] EFI + GRUB2 + Xen - Boot Services issues

[Vladimir 'Ï-coder/phcoder' Serbinenko <phcoder@xxxxxxxxx>]

On 19.03.2014 17:42, Daniel Kiper wrote:
> Hey,
> 
> On Thu, Mar 06, 2014 at 08:29:25PM +0100, Daniel Kiper wrote:
>> Hi,
>>
>> Vladimir, during my work on final multiboot2 protocol support in Xen on
>> EFI platform I stated that GRUB2 patch 
>> 0df77d793c0436be656f982d96d4edaea4993f96
>> (Implement multiboot2 EFI BS specification) may not give access to Boot
>> Services as we earlier expected.
>>
>> In general above mentioned patch gives a way to prevent ExitBootServices()
>> call in GRUB2 which is good. However, it looks that this is only part of
>> the bigger puzzle. Sadly GRUB2 before jumping into the loaded image switches
>> x86 processor mode to 32-bit and disables PG bit in CR0. This is not native
>> EFI processor mode. Especially it is very painful on 64-bit EFI 
>> implementations.
>> Even if you can disable ExitBootServices() call later you are not able to 
>> call
>> Boot Services functions without switching processor mode (this is quite 
>> simple)
>> and recreating page tables (this could be quite complicated). I do not 
>> mention
>> that system table could be unavailable in 32-bit mode because pointer to it
>> is 64-bit and there is no guarantee that it will be placed below 4 GiB. 
>> However,
>> worst thing is that there is no access to ImageHandle which is needed to call
>> ExitBootServices(). Hence, I think that if MULTIBOOT2_HEADER_TAG_EFI_BS tag
>> is in force at least GRUB2 loader should not touch processor mode on EFI 
>> platform
>> and it should pass pointer to ImageHandle. I am aware that this is very 
>> intrusive
>> change and maybe we should consider reverting 
>> 0df77d793c0436be656f982d96d4edaea4993f96
>> (Implement multiboot2 EFI BS specification) patch from GRUB2 version 2.02 at 
>> this
>> stage of development because there is no guarantee that this change will 
>> solve
>> all problems with BS. This way we avoid situation in which new feature is 
>> broken
>> from the beginning and we are not able to remove it.
>>
>> Additionally, I discovered that BS could be overwritten during relocation 
>> because
>> grub_relocator32_boot() is called with last argument (avoid_efi_bootservices)
>> set to 0 even if MULTIBOOT2_HEADER_TAG_EFI_BS tag is in force.
> 
> Is there anybody out there?
> 
Sorry, I was travelling. I've seen your mail, just didn't respond to it
yet. In nutshell, I think that even in current form it's still useful to
allow payloads to follow 32-bit path as long as they wish to keep it and
still use BS if they need to. I'll fix clobbering problem. As for long
mode entry, it's separate issue, I'm thinking about. There are couple of
problems including where to place the paging tables.
> Daniel
>

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel