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

Improved EFI support towards Windows guest #114

Merged

Conversation

rbradford
Copy link
Member

This is the subset of patches from #110 without the integration tests for Windows. I would like to merge these and then make a new release here and use that in CH's upcoming release. However the Windows integration tests here need a fix that is not yet in a released CH.

retrage added 7 commits April 20, 2021 09:53
The Windows bootloader seems to use the function to calibrate the clock
and timer.

Signed-off-by: Akira Moroo <[email protected]>
As per UEFI Specification 2.8[1] section 2.3.4, the stack space is 128 KiB
or more for x64.

[1]
https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf

Signed-off-by: Akira Moroo <[email protected]>
This is a workaround for Windows10 20H2 BSoD.

Signed-off-by: Akira Moroo <[email protected]>
The "fat" LTO causes stuck on Windows 10 20H2 boot with release build.

Signed-off-by: Akira Moroo <[email protected]>
The workaround introduced in ff50324 causes kernel panic on the recent
Linux kernel during calling RuntimeServices.set_virtual_address_map.
This is because the region reported as RuntimeServicesData type is
actually text section which seems to be mapped to non-executable pages.
In this commit, it registers the text section as RuntimeServicesCode and
the other firmware regions are reported as RuntimeServicesData.

Signed-off-by: Akira Moroo <[email protected]>
@rbradford rbradford requested a review from retrage April 22, 2021 15:07
@retrage retrage merged commit 2c9ca2f into cloud-hypervisor:master Apr 22, 2021
@rbradford rbradford deleted the 2021-04-22-initial-windows-enabling branch April 22, 2021 15:38
@rbradford
Copy link
Member Author

@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.

@retrage
Copy link
Contributor

retrage commented Apr 26, 2021

@rbradford I got a different error, and the previous commit 282ebc0 works too.

SAC><?xml><BP>                                                                  
<INSTANCE CLASSNAME="BLUESCREEN">                                               
<PROPERTY NAME="STOPCODE" TYPE="string"><VALUE>"0xF7"</VALUE></PROPERTY><machine
-info>                                                                          
<name>WIN-BT99FD4FLNQ</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>                                                                           
DRIVER_OVERRAN_STACK_BUFFER                                                     
                                                                                
                                                                                
0xFFFFFA8DE9E06278                                                              
0x00009C9C1168FBB2                                                              
0xFFFF6363EE97044D                                                              
0x0000000000000000

I had to run regression tests before pushing them...
Let's take a look at the issue in the new issue #115.

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

Successfully merging this pull request may close these issues.

2 participants