Skip to content
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

Open
retrage opened this issue Apr 26, 2021 · 1 comment
Open

EFI memory map compatibility #115

retrage opened this issue Apr 26, 2021 · 1 comment

Comments

@retrage
Copy link
Contributor

retrage commented Apr 26, 2021

@retrage After your last commit I have to admit I didn't retest Windows. Did it work for you? I get the following error:

<INSTANCE CLASSNAME="BLUESCREEN">                                               
<PROPERTY NAME="STOPCODE" TYPE="string"><VALUE>"0x1E"</VALUE></PROPERTY><machine-info>
<name>WIN-L3C8M6IQS0Q</name>                                                    
<guid>00000000-0000-0000-0000-000000000000</guid>                               
<processor-architecture>AMD64</processor-architecture>
<os-version>10.0</os-version>
<os-build-number>17763</os-build-number>
<os-product>Windows Server 2019</os-product>
<os-service-pack>None</os-service-pack>
</machine-info>

</INSTANCE>
</BP>
!SAC>
KMODE_EXCEPTION_NOT_HANDLED


0xFFFFFFFFC0000005
0xFFFFF8024AEB51F1
0x0000000000000000
0x000000000011A0D0

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)

@retrage
Copy link
Contributor Author

retrage commented Apr 26, 2021

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant