-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EFI memory map compatibility #115
Comments
Both Linux and Windows also use MemoryAttributeTable along with an EFI memory map to set the RuntimeServices page attributes. |
retrage
added a commit
to retrage/rust-hypervisor-firmware
that referenced
this issue
May 3, 2021
On current design, RuntimeServices.set_virtual_address_map overwrites all function pointers in the RuntimeServices to not_available function to avoid calling original functions on runtime phase. However, the Windows Hardware Abstraction Layer (HAL) stores the original RuntimeServices function addresses before the phase and uses the functions afterwards. This behavior causes invalid memory access error because this firmware does not do self-relocation. On Windows, it to use EFI variables on runtime phase (See issue cloud-hypervisor#115). Signed-off-by: Akira Moroo <[email protected]>
retrage
added a commit
to retrage/rust-hypervisor-firmware
that referenced
this issue
May 5, 2021
On current design, RuntimeServices.set_virtual_address_map overwrites all function pointers in the RuntimeServices to not_available function to avoid calling original functions on runtime phase. However, the Windows Hardware Abstraction Layer (HAL) stores the original RuntimeServices function addresses before the phase and uses the functions afterwards. This behavior causes invalid memory access error because this firmware does not do self-relocation. On Windows, it to use EFI variables on runtime phase (See issue cloud-hypervisor#115). Signed-off-by: Akira Moroo <[email protected]>
retrage
added a commit
that referenced
this issue
May 7, 2021
On current design, RuntimeServices.set_virtual_address_map overwrites all function pointers in the RuntimeServices to not_available function to avoid calling original functions on runtime phase. However, the Windows Hardware Abstraction Layer (HAL) stores the original RuntimeServices function addresses before the phase and uses the functions afterwards. This behavior causes invalid memory access error because this firmware does not do self-relocation. On Windows, it to use EFI variables on runtime phase (See issue #115). Signed-off-by: Akira Moroo <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@retrage After your last commit I have to admit I didn't retest Windows. Did it work for you? I get the following error:
Going back to 282ebc0 makes Windows boot fine. So I think there needs to be a little bit more refinement on the memory map.
Originally posted by @rbradford in #114 (comment)
The text was updated successfully, but these errors were encountered: