virtio-win / kvm-guest-drivers-windows

Windows paravirtualized drivers for QEMU\KVM
https://www.linux-kvm.org/page/WindowsGuestDrivers
BSD 3-Clause "New" or "Revised" License
2.04k stars 387 forks source link

EWDK: building ivshmem-test fails with "C1083: Cannot open include file: 'SDKDDKVer.h'" #536

Closed rob-scheepens closed 3 years ago

rob-scheepens commented 3 years ago

I've started to experiment with building the drivers using EWDK, 1809 at first, to remove the VS dependencies. I setup Windows Server 2019 core, so no ui. I downloaded EWDK 1809 on it, and installed winfsp and cpdk on it, as well as the 1809 sdk, needed for windows.h. Short setup for winfsp and 1809 sdk: choco install -y winfsp windows-sdk-10-version-1809-all For cpdk I used:

wget https://download.microsoft.com/download/1/7/6/176909B0-50F2-4DF3-B29B-830A17EA7E38/CPDK_RELEASE_UPDATE/cpdksetup.exe -outfile cpdksetup.exe
cpdksetup.exe /features + /quiet

After that, I ran msbuild -p:Configuration=Win10%20Release -p:Platform=x64, and that fails on:

Project "C:\git\kvm-guest-drivers-windows\virtio-win.sln" (1) is building "C:\git\kvm-guest-drivers-windows\ivshmem\test\ivshmem-test.vcxproj" (12) on node 1 (default targets).
Virtio-Win:
  Driver.Initial.props: _NT_TARGET_VERSION=0x0A00 SUBSYSTEM_NATVER= mismatch=
InitializeBuildStatus:
  Touching "objfre_win10_amd64\amd64\ivshmem-test.tlog\unsuccessfulbuild".
ClCompile:
  C:\ewdk_1809\Program Files\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\CL.exe /c /Zi /nologo /W3 /WX- /diagnostics:classic /sdl /O2 /Oi /GL /D WIN32 /D NDEBUG /D _C
  ONSOLE /D COPYRIGHT_CURRENT_YEAR=2020 /D VENDOR_VER=RHEL.ver /D VER_OS=Win10 /D VER_ARCH=x64 /D "RHEL_COPYRIGHT_STARTING_YEAR=20??" /D _BUILD_MAJOR_VERSION_=101 /D _BUILD_MINOR_VERSION_=58000 /D _NT_TAR
  GET_MAJ=100 /D _RHEL_RELEASE_VERSION_=6 /D _UNICODE /D UNICODE /Gm- /EHsc /MT /GS /Gy /fp:precise /Qspectre /Zc:wchar_t /Zc:forScope /Zc:inline /Yc"stdafx.h" /Fp"objfre_win10_amd64\amd64\ivshmem-test.pc
  h" /Fo"objfre_win10_amd64\amd64\\" /Fd"objfre_win10_amd64\amd64\vc141.pdb" /Gd /TP /FC /errorReport:queue stdafx.cpp
  stdafx.cpp
c:\git\kvm-guest-drivers-windows\ivshmem\test\targetver.h(8): fatal error C1083: Cannot open include file: 'SDKDDKVer.h': No such file or directory [C:\git\kvm-guest-drivers-windows\ivshmem\test\ivshmem-t
est.vcxproj]
Done Building Project "C:\git\kvm-guest-drivers-windows\ivshmem\test\ivshmem-test.vcxproj" (default targets) -- FAILED.

I thought it's because that project is of an older version of VS, but it's not. The SDKDDKVer.h seems to be present in C:\ewdk_1809\Program Files\Windows Kits\10\Include\10.0.17763.0\shared, and that's included in my path:

Path=C:\ewdk_1809\Program Files\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86;C:\ewdk_1809\Program Files\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\bin\Roslyn;x86;C:\ewdk_1809\Program Files\Microsoft Visual Studio\2017\BuildTools\\MSBuild\15.0\bin;C:\Windows\Microsoft.NET\Framework\v4.0.30319;C:\ewdk_1809\Program Files\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\;C:\ewdk_1809\Program Files\Microsoft Visual Studio\2017\BuildTools\Common7\Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\ProgramData\chocolatey\bin;C:\Program Files\OpenSSH-Win64;C:\Program Files\Git\cmd;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Users\Administrator\AppData\Local\Microsoft\WindowsApps;;C:\ewdk_1809\Program Files\Windows Kits\10\\bin\10.0.17763.0\x86;C:\ewdk_1809\Program Files\Windows Kits\10\\Tools\bin\i386;C:\ewdk_1809\Program Files\Windows Kits\10\\tools;C:\ewdk_1809\Program Files\Windows Kits\10\\tools\ARM64;C:\ewdk_1809\BuildEnv;"C:\Program Files (x86)\Windows Kits\10\Include";"C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um";"C:\ewdk_1809\Program Files\Windows Kits\10\Include\10.0.17763.0\shared"

Then again, EWDK is using VS2017 while the project is defined for VS2015. Could that be it? I changed WindowsTargetPlatformVersion to 10.0.17763.0 from the original 8.1, but that did not make a difference.

YanVugenfirer commented 3 years ago

Adding Yuri @ybendito

rob-scheepens commented 3 years ago

I noticed that on the VS build vm in procmon the path C:\Program Files (x86)\Windows Kits\8.1\Include\shared\sdkddkver.h is referenced. I manually copied that file to the EWDK build vm, but that did not make a change. In fact, procmon only shows queries for that file in C:\ewdk_1809\Program Files\Windows Kits\10\Include\10.0.17763.0\shared\sdkddkver.h. Perhaps an env var is missing? I've attached the two procmon runs. sdkddk_filter_procmon.txt

rob-scheepens commented 3 years ago

Opening a support case with Microsoft confirmed that WindowsTargetPlatformVersion should be changed. Several vcxproj files have this set to 8.1, which won't work with EWDK 1809. Changing all instances to $(LatestTargetPlatformVersion) resolved that problem.

Another issue was errors about missing .metaproj files when building using MSBuild. Setting MSBUILDEMITSOLUTION=1 resolved that. Only remaining errors now are:

 C:\git\kvm-guest-drivers-windows\viosock\ViosockPackage\ViosockPackage.vcxproj(197,5): error MSB3030: Could not copy the file "..\lib\x86\Win10Release\viosocklib.pdb" because it was not found.
 C:\git\kvm-guest-drivers-windows\viosock\ViosockPackage\ViosockPackage.vcxproj(197,5): error MSB3030: Could not copy the file "..\lib\x86\Win10Release\viosocklib.dll" because it was not found.

These can be explained since https://github.com/virtio-win/kvm-guest-drivers-windows/blob/57eee37e5ccfee280d35de2998b30baa34d555cd/viosock/ViosockPackage/ViosockPackage.vcxproj#L188 also lists these x86 files even when only building x64. I need to dig into why this dependency for x86 files is present, but that is of lower priority, since the build still works. Easy workaround is to build x86 before x64, then build succeeds 100%.

Additionally, EWDK 1809 generates various warnings 1303:

C:\git\kvm-guest-drivers-windows\viorng\viorng\viorng.inf(98-98): warning 1303: Found legacy AddReg operation defining co-installers (CoInstallers32). [C:\git\kvm-guest-drivers-windows\viorng\VirtRNG Pa
ckage\VirtRNG Package.vcxproj]
C:\git\kvm-guest-drivers-windows\viosock\sys\viosock_wow_co.inx(99-99): warning 1303: Found legacy AddReg operation defining co-installers (CoInstallers32). [C:\git\kvm-guest-drivers-windows\viosock\sys
\viosock.vcxproj]

For now these warnings don't block building, but I'll create a new issue for this.

YanVugenfirer commented 3 years ago

C:\git\kvm-guest-drivers-windows\viorng\viorng\viorng.inf(98-98): warning 1303: Found legacy AddReg operation defining co-installers (CoInstallers32). [C:\git\kvm-guest-drivers-windows\viorng\VirtRNG Pa ckage\VirtRNG Package.vcxproj] C:\git\kvm-guest-drivers-windows\viosock\sys\viosock_wow_co.inx(99-99): warning 1303: Found legacy AddReg operation defining co-installers (CoInstallers32). [C:\git\kvm-guest-drivers-windows\viosock\sys \viosock.vcxproj]

Most probably we need to solve this on the installer level. Additional components should be installed with the driver in both cases. On other hand, AddReg is breaking the "Universal" platform target.

irudakov77 commented 3 years ago

Hi,

also lists these x86 files even when only building x64. I need to dig into why this dependency for x86 files is present, but that is of lower priority, since the build still works. Easy workaround is to build x86 before x64, then build succeeds 100%.

WOW64. x86 apps require x86 socket provider, it should be installed along with x64 provider on Windows x64. Thus it is really necessary to build x86 viosock (at least viosocklib.dll) before x64.

C:\git\kvm-guest-drivers-windows\viosock\sys\viosock_wow_co.inx(99-99): warning 1303: Found legacy AddReg operation defining co-installers (CoInstallers32). [C:\git\kvm-guest-drivers-windows\viosock\sys \viosock.vcxproj]

Remove 1 from Tools\Driver.RHEL.props to avoid this warning. But you should implement explicit installer for socket provider(s) in this case.

Regards, Ilya

ybendito commented 3 years ago

I do not exactly understand why we need to focus now on warnings. Probably better idea is to spawn the task of converting coinstallers (deprecated for universal drivers, i.e. actually for ARM) to extension INF which is legitimate method of spawning software installation as a result of hardware installation.

rob-scheepens commented 3 years ago

This is fixed by https://github.com/virtio-win/kvm-guest-drivers-windows/pull/542.