virtio-win / kvm-guest-drivers-windows

Windows paravirtualized drivers for QEMU\KVM

KVM/QEMU Windows guest drivers (virtio-win)

This repository contains KVM/QEMU Windows guest drivers, for both paravirtual and emulated hardware. The code builds and ships as part of the virtio-win RPM on Fedora and Red Hat Enterprise Linux, and the binaries are also available in the form of distribution-neutral ISO and VFD images. If all you want is use virtio-win in your Windows virtual machines, go to the Fedora virtIO-win documentation for information on obtaining the binaries.

If you'd like to build virtio-win from sources, clone this repo and follow the instructions in Building the Drivers. Note that the drivers you build will be either unsigned or test-signed with Tools/VirtIOTestCert.cer, which means that Windows will not load them by default. See Microsoft's driver signing page for more information on test-signing.

If you want to build cross-signed binaries (like the ones that ship in the Fedora RPM), you'll need your own code-signing certificate. Cross-signed drivers can be used on all versions of Windows except for the latest Windows 10 with secure boot enabled. However, systems with cross-signed drivers will not receive Microsoft support.

If you want to produce Microsoft-signed binaries (fully supported, like the ones that ship in the Red Hat Enterprise Linux RPM), you'll need to submit the drivers to Microsoft along with a set of test results (so called WHQL process). If you decide to WHQL the drivers, make sure to base them on commit eb2996de or newer, since the GPL license used prior to this commit is not compatible with WHQL. Additionally, we ask that you make a change to the Hardware IDs so that your drivers will not match devices exposed by the upstream versions of KVM/QEMU. This is especially important if you plan to distribute the drivers with Windows Update, see the Microsoft publishing restrictions for more details.

---

kvm-guest-drivers-windows's Issues

Network connections toggle after reboot with NetKVM version 60.63.103.nnnn on Windows Server 2008 R2

Periodically I test newly available virtio-win drivers on Windows Server 2008 R2. I noticed that since version 60.63.103.2200 there are issues with bridged networking on el6. When I install the driver all appears well, but after a reboot there is no network connectivity anymore. When the VM is rebooted again, network connectivity is back. But network connectivity keeps "toggling" after each reboot. The host OS is Centos 6 currently 6.3. On 6.2 I had the same issues with NetKVM.

I also tested http://people.redhat.com/vrozenfe/build-29/ and build-27 with the same result.

The NetKVM driver I currently use without the "connectivity toggle issue" is 60.62.102.2000.

What can I do to resolve this problem? Am I the only one experiencing this problem?

Any plans for virtio-vga device?

I have no idea if that makes sense, given the existence of QXL - just asking.

Deadlock in netkvm with iscsi

Used the Windows kernel debugger to figure out a deadlock that was occurring with netkvm sporadically. The problem appears to be a side effect of design choices to not release NDIS locks right away. My solution was to use a separate interface with the E1000 driver for iSCSI traffic but wanted to bring the issue up in case others ran into the same problem.

Here's the stack trace from the Windows kernel debugger (one for each processor thread):

2: kd> 0kv 123
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff801`74698350 fffff801`730f0be2 : 00000000`00000002 00000000`00989680 fffff801`74698480 ffffe000`a1925870 : nt!KxWaitForSpinLockAndAcquire+0x22
fffff801`74698380 fffff800`3c00942d : ffffe000`a1683c70 fffff800`3c009e90 ffffe000`a1925870 ffffe000`9f865630 : nt!KeAcquireSpinLockRaiseToDpc+0x32
(Inline Function) --------`-------- : --------`-------- --------`-------- --------`-------- --------`-------- : netkvm!CNdisSpinLock::Lock+0xa (Inline Function @ fffff800`3c00942d) [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-util.h @ 71]
(Inline Function) --------`-------- : --------`-------- --------`-------- --------`-------- --------`-------- : netkvm!CLockedContext<CNdisSpinLock>::{ctor}+0xa (Inline Function @ fffff800`3c00942d) [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-util.h @ 90]
(Inline Function) --------`-------- : --------`-------- --------`-------- --------`-------- --------`-------- : netkvm!CParaNdisTX::DoWithTXLock+0xa (Inline Function @ fffff800`3c00942d) [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.h @ 196]
fffff801`746983b0 fffff800`3c009b78 : 00000000`00000001 ffffe000`a1925870 ffffe000`9fd32c60 00000000`00000000 : netkvm!CParaNdisTX::NBLMappingDone+0x25 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 310]
fffff801`746983e0 fffff801`73019a37 : 00000000`00000108 ffffe000`a199df30 ffffe000`a0ca4b70 ffffe000`a0ca4b70 : netkvm!CNBL::RegisterMappedNB+0x6c [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 77]
fffff801`74698410 fffff800`3b058e82 : ffffe000`a0ca4b70 ffffe000`9f420050 ffffe000`a0ca4b70 ffffe000`a0ca4bb0 : hal!HalBuildScatterGatherListV2+0x207
fffff801`746984b0 fffff800`3c009d46 : 00000000`00000000 fffff801`731460ca ffffe000`a0aa1b90 00000000`000089e0 : NDIS!NdisMAllocateNetBufferSGList+0x1a2
fffff801`74698570 fffff800`3c00871e : 00000000`00000000 00000000`00000001 ffffe000`9f4201a0 fffff800`3c009678 : netkvm!CNB::ScheduleBuildSGListForTx+0x2e [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 650]
(Inline Function) --------`-------- : --------`-------- --------`-------- --------`-------- --------`-------- : netkvm!CNBL::StartMapping::__l6::<lambda_ea34f6eaf6f02c2b80267054dd87e843>::operator()+0x8 (Inline Function @ fffff800`3c00871e) [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 240]
fffff801`746985b0 fffff800`3c00a243 : ffffe000`a1925802 ffffe000`a1925870 ffffe000`a0ca4aa0 ffffe000`a0ca4940 : netkvm!CNdisList<CNB,CRawAccess,CNonCountingObject>::ForEachDetached<<lambda_ea34f6eaf6f02c2b80267054dd87e843> >+0x3a [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-util.h @ 241]
fffff801`746985e0 fffff800`3c009e51 : ffffe000`a1925870 ffffe000`9f865630 ffffe000`9f865630 ffffe000`a0fdd4e8 : netkvm!CNBL::StartMapping+0x27 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 247]
fffff801`74698610 fffff800`3c00db9a : fffff800`3b4011a0 00000000`00000000 00000000`00000000 ffffe000`9fd34860 : netkvm!CParaNdisTX::Send+0xfd [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 296]
fffff801`74698710 fffff800`3b056fb1 : 00000000`00000000 00000000`00000010 00000000`000088e0 fffff800`3b877117 : netkvm!ParaNdis6_SendNetBufferLists+0x46 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\wlh\parandis6-driver.cpp @ 529]
fffff801`74698740 fffff800`3b88bee9 : ffffe000`9fdb5b00 ffffe000`a0ca4940 00000000`00000000 00000000`00000000 : NDIS!NdisSendNetBufferLists+0x551
fffff801`74698930 fffff800`3b88ae63 : 00000001`00000001 fffff800`3b051301 00000000`00008cdc fffff800`2e83bc3f : tcpip!FlFastSendPackets+0xf1
fffff801`74698990 fffff800`3b88a98c : ffffe000`9f420100 00000000`00000014 ffffe000`9fe327e0 ffffe000`9fdb0000 : tcpip!IpNlpFastContinueSendDatagram+0x363
fffff801`74698a70 fffff800`3b8753b9 : ffffb6a6`3206b600 00000000`004d6001 00000000`00000014 ffffe000`9fe327e0 : tcpip!IpNlpFastSendDatagram+0x308
fffff801`74698b70 fffff800`3b86abc5 : ffffe000`9f0574e0 00000000`00000000 00000000`00000001 ffffe000`a1834040 : tcpip!TcpTcbSend+0x78d
fffff801`74698ec0 fffff800`3b86a80c : 00000000`004d607a 00000000`00989680 00000000`00000000 fffff801`746991f0 : tcpip!TcpEnqueueTcbSendOlmNotifySendComplete+0xa5
fffff801`74698ef0 fffff800`3b86acc8 : 00000000`00000000 00000000`00000000 ffffe000`a00e0d10 fffff800`3b28c6fd : tcpip!TcpEnqueueTcbSend+0x2ac
fffff801`74698ff0 fffff801`7313cf63 : ffffe000`9fa1101e 00000000`00000000 ffffe000`9f439740 fffff801`7301969a : tcpip!TcpTlConnectionSendCalloutRoutine+0x28
fffff801`74699070 fffff800`3b86af86 : fffff800`3b86aca0 fffff801`74699190 ffffe000`a4631110 fffff801`746991b8 : nt!KeExpandKernelStackAndCalloutInternal+0xf3
fffff801`74699160 fffff800`3b345f9f : ffffe000`a00e0d00 fffff800`3c152010 00000000`00000000 00000000`00000001 : tcpip!TcpTlConnectionSend+0x76
fffff801`746991d0 fffff800`3c12d2c3 : ffffe000`a0382200 ffffe000`a0401840 ffffe000`a0400000 00000000`00000000 : afd!WskProIRPSend+0xbf
fffff801`74699240 fffff800`3c1388e6 : ffffe000`00000000 ffffe000`a0582800 ffffe000`a0401410 ffffe000`a46311e0 : msiscsi!iSpSendData+0x143
fffff801`746992a0 fffff800`3c13b068 : ffffe000`a4631101 ffffe000`a0582801 ffffe000`a46311e0 ffffe000`a0582800 : msiscsi!iSpProcessScsiCommand+0x2ce
fffff801`74699300 fffff800`3c13ab5d : 00000000`00000000 ffffe000`a19cfea0 00000000`00000000 ffffe000`a0401a20 : msiscsi!iSpScsiCommandPostProcess+0x488
fffff801`74699360 fffff800`3c13e4e5 : 00000000`00000000 00000000`00000000 00000000`00000000 ffffffff`2c720828 : msiscsi!iSpProcessScsiResponse+0x4f9
fffff801`746993e0 fffff800`3c12d7c8 : 00000000`00000000 ffffe000`a0401a20 ffffe000`a0582800 ffffe000`a14a1300 : msiscsi!iSpProcessResponse+0x365
fffff801`74699440 fffff801`7311b84e : 00000000`00000000 ffffe000`a17ac430 fffff801`746995a0 00000000`00000048 : msiscsi!iSpSendCompletion+0x1ac
fffff801`746994a0 fffff800`3b345d22 : ffffe000`a17ac430 00000000`00000002 00000000`0000000c 00000000`00000000 : nt!IopfCompleteRequest+0x2ee
fffff801`746995e0 fffff800`3b8776d7 : ffffe000`9feab190 00000000`00000000 00000000`00000001 ffffe000`9feab2a0 : afd!WskProTLSendOrDisconnectComplete+0x72
fffff801`74699640 fffff800`3b168193 : ffffd001`0cdfd500 00000000`00000000 ffffe000`9f781010 ffffe000`a1ed00d0 : tcpip!TcpTcbSendDatagramsComplete+0x194
fffff801`746996b0 fffff800`3b874ab7 : 00000000`00000000 00000000`00000001 00000000`00000000 ffffe000`9feab030 : NETIO!NetioDereferenceNetBufferListChain+0xd3
fffff801`74699750 fffff800`3b058690 : 00000000`00000001 fffff801`746997e9 ffffe000`9f4201a0 00000000`00001ed9 : tcpip!FlSendNetBufferListChainComplete+0x57
fffff801`74699780 fffff800`3b057f01 : ffffe000`9f4201a0 ffffe000`9feab030 00000000`00000001 ffffe000`4c4e4800 : NDIS!ndisMSendCompleteNetBufferListsInternal+0x140
fffff801`74699850 fffff800`3c0092d9 : ffffe000`9f4201a0 ffffe000`9feab030 ffffe000`9f8af010 ffffe000`9f8655a0 : NDIS!NdisMSendNetBufferListsComplete+0x4f1
fffff801`746999c0 fffff800`3c003290 : 00000000`00000000 00000000`00000001 00000000`00000000 ffffe000`9feab030 : netkvm!CParaNdisTX::DoPendingTasks+0xad [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 610]
fffff801`74699a70 fffff800`3c00e2d0 : ffffe000`9f8af010 fffff801`74699b79 00000000`00000000 00000000`00000001 : netkvm!ParaNdis_DPCWorkBody+0x104 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-common.cpp @ 1715]
fffff801`74699aa0 fffff800`3b053e12 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : netkvm!MiniportMSIInterruptDpc+0x2c [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\wlh\parandis6-impl.cpp @ 399]
fffff801`74699b00 fffff801`7310f4d0 : 00000000`ffffffff fffff801`7336e790 00000000`00000001 fffff801`7301958f : NDIS!ndisInterruptDpc+0x1a3
fffff801`74699be0 fffff801`7310e817 : 00000000`00000000 ffffe000`9ee8b880 fffff801`73381180 fffff801`00000001 : nt!KiExecuteAllDpcs+0x1b0
fffff801`74699d30 fffff801`731d49d5 : 00000000`00000000 fffff801`73381180 ffffd001`0cdfd3c0 fffffa80`060ad8b0 : nt!KiRetireDpcList+0xd7
fffff801`74699fb0 fffff801`731d47d9 : ffffe000`a186d600 ffffe000`a00f5184 00000000`00000001 ffffe000`a1cbba30 : nt!KxRetireDpcList+0x5 (TrapFrame @ fffff801`74699e70)
ffffd000`2032b350 fffff801`731d6a45 : ffffd001`0cdfd3c0 fffff801`731d2eb3 00000000`00000000 00000000`00000000 : nt!KiDispatchInterruptContinue
ffffd000`2032b380 fffff801`731d2eb3 : 00000000`00000000 00000000`00000000 00000000`00000000 fffff801`73381180 : nt!KiDpcInterruptBypass+0x25
ffffd000`2032b390 fffff801`730edcc7 : ffffe000`a171e080 00000000`00000010 00000000`00000000 00000000`a0000003 : nt!KiInterruptDispatch+0x173 (TrapFrame @ ffffd000`2032b390)
ffffd000`2032b520 fffff801`730ecf84 : 00000000`00000011 00000000`00000001 ffffd000`2032b609 00000000`00000001 : nt!MiProbeLockFrame+0x147
ffffd000`2032b590 fffff800`3b47efef : 00000000`00000010 ffffe000`a16f3001 ffffe000`00000001 ffffe000`a16f3018 : nt!MmProbeAndLockPages+0x254
ffffd000`2032b670 fffff800`3b45dd0f : ffffe000`a16f3018 ffffe000`a1c6c710 ffffe000`a09b9de0 00000000`00000000 : Ntfs!NtfsLockUserBuffer+0x6f
ffffd000`2032b6c0 fffff800`3b471f22 : ffffe000`a16f3018 ffffe000`a1c6c710 ffffe000`a09b9de0 ffffe000`a1cdf000 : Ntfs!NtfsVolumeDasdIo+0xdf
ffffd000`2032b760 fffff800`3b4786de : ffffe000`a16f3018 ffffe000`a1c6c710 00000000`00000000 ffffd000`2032b900 : Ntfs!NtfsCommonRead+0x1f82
ffffd000`2032b900 fffff800`3b2e8101 : ffffe000`a16d9ca0 ffffe000`a1c6c710 ffffe000`a1520660 ffffe000`a1c6c710 : Ntfs!NtfsFsdRead+0x1ee
ffffd000`2032b9b0 fffff801`7344dab0 : 00000000`00000000 ffffd000`2032ba91 ffffe000`a1520660 0000000c`001f0003 : fltmgr!FltpDispatch+0xf1
ffffd000`2032ba10 fffff801`7344b0d6 : ffffe000`a1520604 ffffe000`a1520660 ffffe000`9f5fbe01 ffffe000`a1520660 : nt!IopSynchronousServiceTail+0x160
ffffd000`2032bae0 fffff801`731dd0b3 : 00000000`00000000 00000000`00000568 00000000`00000000 00000082`610decf0 : nt!NtReadFile+0x656
ffffd000`2032bbd0 00007ff9`47e00e8a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffd000`2032bc40)
00000082`610de478 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ff9`47e00e8a

2: kd> 1kv 123
Child-SP          RetAddr           : Args to Child                                                           : Call Site
ffffd001`0cd67aa0 fffff801`730f0be2 : 00000000`00000002 00000000`00989680 ffffd001`0cd67bd0 00000000`00000000 : nt!KxWaitForSpinLockAndAcquire+0x1f
ffffd001`0cd67ad0 fffff800`3c00942d : ffffe000`a1658650 ffffe000`a04018b0 00000000`00000001 ffffe000`9f7cc020 : nt!KeAcquireSpinLockRaiseToDpc+0x32
(Inline Function) --------`-------- : --------`-------- --------`-------- --------`-------- --------`-------- : netkvm!CNdisSpinLock::Lock+0xa (Inline Function @ fffff800`3c00942d) [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-util.h @ 71]
(Inline Function) --------`-------- : --------`-------- --------`-------- --------`-------- --------`-------- : netkvm!CLockedContext<CNdisSpinLock>::{ctor}+0xa (Inline Function @ fffff800`3c00942d) [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-util.h @ 90]
(Inline Function) --------`-------- : --------`-------- --------`-------- --------`-------- --------`-------- : netkvm!CParaNdisTX::DoWithTXLock+0xa (Inline Function @ fffff800`3c00942d) [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.h @ 196]
ffffd001`0cd67b00 fffff800`3c009b78 : 00000000`00000001 ffffe000`a1cbf010 ffffe000`9fd32c60 00000000`00000000 : netkvm!CParaNdisTX::NBLMappingDone+0x25 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 310]
ffffd001`0cd67b30 fffff801`73019a37 : 00000000`00000018 ffffe000`a161c478 ffffe000`a161c440 ffffe000`a161c440 : netkvm!CNBL::RegisterMappedNB+0x6c [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 77]
ffffd001`0cd67b60 fffff800`3b058e82 : ffffe000`a161c440 ffffe000`9f420050 ffffe000`a161c440 ffffe000`a161c480 : hal!HalBuildScatterGatherListV2+0x207
ffffd001`0cd67c00 fffff800`3c009d46 : 00000000`00000000 fffff801`731460ca ffffe000`9ff1f530 00000000`00000101 : NDIS!NdisMAllocateNetBufferSGList+0x1a2
ffffd001`0cd67cc0 fffff800`3c00871e : 00000000`00000000 00000000`00000001 ffffe000`9f4201a0 fffff800`3c0096ec : netkvm!CNB::ScheduleBuildSGListForTx+0x2e [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 650]
(Inline Function) --------`-------- : --------`-------- --------`-------- --------`-------- --------`-------- : netkvm!CNBL::StartMapping::__l6::<lambda_ea34f6eaf6f02c2b80267054dd87e843>::operator()+0x8 (Inline Function @ fffff800`3c00871e) [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 240]
ffffd001`0cd67d00 fffff800`3c00a243 : ffffe000`a1cbf002 ffffe000`a1cbf010 fffff800`3c013fb0 ffffe000`a161c210 : netkvm!CNdisList<CNB,CRawAccess,CNonCountingObject>::ForEachDetached<<lambda_ea34f6eaf6f02c2b80267054dd87e843> >+0x3a [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-util.h @ 241]
ffffd001`0cd67d30 fffff800`3c009e51 : ffffe000`a1cbf010 ffffe000`9f865630 ffffe000`9f865630 ffffe000`a182acf0 : netkvm!CNBL::StartMapping+0x27 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 247]
ffffd001`0cd67d60 fffff800`3c00db9a : fffff800`3b4011a0 00000000`00000000 00000000`00000000 ffffe000`9fd34860 : netkvm!CParaNdisTX::Send+0xfd [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 296]
ffffd001`0cd67e60 fffff800`3b056fb1 : 00000000`00000000 fffffa80`06c01c00 00000000`00000000 00000000`00000001 : netkvm!ParaNdis6_SendNetBufferLists+0x46 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\wlh\parandis6-driver.cpp @ 529]
ffffd001`0cd67e90 fffff800`3b87384b : ffffe000`9fdb5b00 ffffe000`a161c210 ffffe000`00000000 00000000`00000002 : NDIS!NdisSendNetBufferLists+0x551
ffffd001`0cd68080 fffff800`3b872284 : fffff800`3b9ed180 00000000`00000000 ffffe000`00000000 00000000`00000800 : tcpip!IppFragmentPackets+0x4cb
ffffd001`0cd681c0 fffff800`3b871a59 : fffff800`3b9ed180 00000000`00140005 00000003`00000000 00000000`0000912c : tcpip!IppDispatchSendPacketHelper+0x94
ffffd001`0cd68350 fffff800`3b86ffee : 00000000`00000000 ffffe000`9f419b28 00000000`00000002 ffffd001`0cd68780 : tcpip!IppPacketizeDatagrams+0x2d9
ffffd001`0cd684f0 fffff800`3b838468 : ffffe000`9fe24040 fffff800`3b16f607 fffff800`3b9ed180 ffffe000`a14f8d70 : tcpip!IppSendDatagramsCommon+0x49e
ffffd001`0cd686d0 fffff800`3b838182 : 00000075`22ff1d0e ffffe000`9fe70010 ffffe000`9fe70010 ffffe000`a19cfea0 : tcpip!IpNlpSendDatagrams+0x48
ffffd001`0cd68710 fffff800`3b8978d4 : 00000000`00000020 00000000`00000086 346dc5d6`3886594b 00000000`ffffffff : tcpip!TcpTcbKeepAliveSend+0x35a
ffffd001`0cd688c0 fffff800`3b895ed2 : ffffe000`9f1c1000 00000000`004d607b 00000000`00000004 00000000`00000000 : tcpip!TcpFlushDelay+0x633
ffffd001`0cd68970 fffff801`7310ec38 : ffffd001`0cd68c60 00000000`00000001 00000000`00000000 ffffd001`0cd3f180 : tcpip!TcpPeriodicTimeoutHandler+0x833
ffffd001`0cd68b20 fffff801`731d53ea : ffffd001`0cd3f180 ffffd001`0cd3f180 ffffd001`0cd4b2c0 ffffe000`a094b040 : nt!KiRetireDpcList+0x4f8
ffffd001`0cd68da0 00000000`00000000 : ffffd001`0cd69000 ffffd001`0cd63000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x5a

2: kd> 2kv 123
Child-SP          RetAddr           : Args to Child                                                           : Call Site
ffffd001`091a1c88 fffff801`731eebb2 : 00000000`00000000 00000000`6297cb98 00007ac8`44d50002 fffff801`7315bbd8 : nt!DbgBreakPointWithStatus
ffffd001`091a1c90 fffff801`730c3721 : ffffd001`0cdffc04 00000000`005f20e1 ffffe000`9ee676a8 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0xcdf2
ffffd001`091a1d20 fffff801`7301b7b5 : ffffe000`9f32d440 00000000`00000000 ffffd001`0cdffd30 00000000`00000001 : nt!KeClockInterruptNotify+0x91
ffffd001`091a1f40 fffff801`731620f3 : ffff9435`ff99e23f ffffd001`0cdffc80 ffffe000`a0401cec ffffe000`a0401a20 : hal!HalpTimerClockIpiRoutine+0x15
ffffd001`091a1f70 fffff801`731d2d2a : ffffe000`9f000300 ffffe000`9f8af2e0 00000000`00000000 ffffe000`a11ad4a0 : nt!KiCallInterruptServiceRoutine+0xa3
ffffd001`091a1fb0 fffff801`731d310f : ffffe000`9f866570 00000000`00000000 00000000`00000000 00001f80`000002bd : nt!KiInterruptSubDispatchNoLockNoEtw+0xea (TrapFrame @ ffffd001`091a1e70)
ffffd001`09191360 fffff801`730f0c1b : ffffe000`9f865660 00000000`00010008 ffffd001`091915c0 ffffd001`09191520 : nt!KiInterruptDispatchLBControl+0x11f (TrapFrame @ ffffd001`09191360)
ffffd001`091914f0 fffff800`3c00843f : ffffe000`9f865660 ffffd001`091915a9 ffffe000`9f865630 ffffd001`091915c0 : nt!KxWaitForSpinLockAndAcquire+0x1f
(Inline Function) --------`-------- : --------`-------- --------`-------- --------`-------- --------`-------- : netkvm!CParaNdisTX::DoPendingTasks::__l8::<lambda_0d1768a7969216d060dd330cbb84655c>::operator()+0x6a (Inline Function @ fffff800`3c00843f) [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 586]
ffffd001`09191520 fffff800`3c0092a1 : ffffe000`9f865630 ffffe000`9f865630 ffffd001`091915f0 ffffd001`091915f8 : netkvm!CParaNdisTX::DoWithTXLock<<lambda_0d1768a7969216d060dd330cbb84655c> >+0x87 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.h @ 197]
ffffd001`09191560 fffff800`3c009473 : 00000000`00000000 fffff800`3c009b00 00000000`00000000 00000000`00000000 : netkvm!CParaNdisTX::DoPendingTasks+0x75 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 597]
ffffd001`09191610 fffff800`3c009b78 : 00000000`00000001 ffffe000`9f658ed0 ffffe000`9fd32c60 00000000`00000000 : netkvm!CParaNdisTX::NBLMappingDone+0x6b [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 313]
ffffd001`09191640 fffff801`73019a37 : 00000000`00000030 ffffe000`a10bacc8 ffffe000`a1d0f810 ffffe000`a1d0f810 : netkvm!CNBL::RegisterMappedNB+0x6c [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 77]
ffffd001`09191670 fffff800`3b058e82 : ffffe000`a1d0f810 ffffe000`9f420050 ffffe000`a1d0f810 ffffe000`a1d0f850 : hal!HalBuildScatterGatherListV2+0x207
ffffd001`09191710 fffff800`3c009d46 : 00000000`00000000 fffff801`731460ca ffffe000`a1935560 00000000`000006b4 : NDIS!NdisMAllocateNetBufferSGList+0x1a2
ffffd001`091917d0 fffff800`3c00871e : 00000000`00000000 00000000`00000001 ffffe000`9f4201a0 fffff800`3c0096ec : netkvm!CNB::ScheduleBuildSGListForTx+0x2e [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 650]
(Inline Function) --------`-------- : --------`-------- --------`-------- --------`-------- --------`-------- : netkvm!CNBL::StartMapping::__l6::<lambda_ea34f6eaf6f02c2b80267054dd87e843>::operator()+0x8 (Inline Function @ fffff800`3c00871e) [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 240]
ffffd001`09191810 fffff800`3c00a243 : ffffe000`9f658e02 ffffe000`9f658ed0 fffff800`3c013fb0 ffffe000`a1d0f5e0 : netkvm!CNdisList<CNB,CRawAccess,CNonCountingObject>::ForEachDetached<<lambda_ea34f6eaf6f02c2b80267054dd87e843> >+0x3a [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-util.h @ 241]
ffffd001`09191840 fffff800`3c009e51 : ffffe000`9f658ed0 ffffe000`9f865630 ffffe000`9f865630 fffff800`3c001f59 : netkvm!CNBL::StartMapping+0x27 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 247]
ffffd001`09191870 fffff800`3c00db9a : fffff800`3b4011a0 00000000`00000000 00000000`00000000 ffffe000`9fd34860 : netkvm!CParaNdisTX::Send+0xfd [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 296]
ffffd001`09191970 fffff800`3b056fb1 : 00000000`00000000 ffffe000`9f3fb001 00000000`00000000 00000000`00000001 : netkvm!ParaNdis6_SendNetBufferLists+0x46 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\wlh\parandis6-driver.cpp @ 529]
ffffd001`091919a0 fffff800`3b87384b : ffffe000`9fdb5b00 ffffe000`a1d0f5e0 ffffe000`00000000 00000000`00000002 : NDIS!NdisSendNetBufferLists+0x551
ffffd001`09191b90 fffff800`3b872284 : fffff800`3b9ed180 00000000`00000000 ffffe000`00000000 ffffd001`09190800 : tcpip!IppFragmentPackets+0x4cb
ffffd001`09191cd0 fffff800`3b871a59 : fffff800`3b9ed180 00000000`00140005 00000000`00000000 00000000`0000dcf9 : tcpip!IppDispatchSendPacketHelper+0x94
ffffd001`09191e60 fffff800`3b86ffee : ffffe000`a00c9230 ffffe000`9f419568 00000000`00000002 ffffd001`091922a0 : tcpip!IppPacketizeDatagrams+0x2d9
ffffd001`09192000 fffff800`3b838468 : 00000000`00000000 ffffd001`09192207 fffff800`3b9ed180 ffffe000`a0f79d70 : tcpip!IppSendDatagramsCommon+0x49e
ffffd001`091921e0 fffff800`3b8b8983 : 00000000`0000111c ffffd001`09192378 00000000`00000002 00000000`2e82e93b : tcpip!IpNlpSendDatagrams+0x48
ffffd001`09192220 fffff800`3b8955a7 : 00000000`00000014 ffffe000`9f0574e0 00000000`00000000 00000000`00000002 : tcpip!TcpSackRetransmitTcbSend+0x283
ffffd001`091923e0 fffff800`3b8787ce : ffffe000`a12943b0 00000000`2e81dd2f 00000000`2e81f3ff 00000000`2e81f3ff : tcpip!TcpTcbProcessCarefulCumulativeAcknowledgement+0x173
ffffd001`09192470 fffff800`3b86d072 : 00000001`0018300c 00000000`00000000 ffffe000`9f865560 fffff800`3c0082e6 : tcpip!TcpTcbCarefulDatagram+0x3fe
ffffd001`09192780 fffff800`3b86db00 : 00000000`00000000 00000000`00000000 ffffe000`a1660df0 ffffe000`9f1c1e80 : tcpip!TcpTcbReceive+0x3a2
ffffd001`091928d0 fffff800`3b86c8b3 : ffffe000`9f954022 ffffe000`9f40c280 00000000`00000000 ffffe000`9f12efd0 : tcpip!TcpMatchReceive+0x1f0
ffffd001`09192a60 fffff800`3b8a248f : ffffe000`9f1ee130 ffffd001`09192cd8 ffffd001`091960c0 ffffe000`9feab260 : tcpip!TcpPreValidatedReceive+0x363
ffffd001`09192b60 fffff800`3b89e80b : ffff9ea6`4f761a05 fffff800`3c00efec ffffe000`a14a0ec0 00000000`00000001 : tcpip!IppDeliverListToProtocol+0x4f
ffffd001`09192c20 fffff800`3b89cc62 : 00000000`00000000 ffffd001`09192d39 00000000`00000006 ffffe000`9f4201a0 : tcpip!IppProcessDeliverList+0x6b
ffffd001`09192c80 fffff800`3b89b040 : fffffa80`06c01c00 ffffe000`a11f0030 ffffe000`9f40c000 ffffe000`9f40c000 : tcpip!IppReceiveHeaderBatch+0x232
ffffd001`09192da0 fffff800`3b899462 : ffffe000`9fe32c30 00000000`00000000 ffffd001`09193101 ffffe000`a1f30000 : tcpip!IppFlcReceivePacketsCore+0x680
ffffd001`09193120 fffff800`3b899e85 : ffffe000`9fdb0002 00000000`00000000 fffff800`3b899ed0 00000000`00000101 : tcpip!FlpReceiveNonPreValidatedNetBufferListChain+0x318
ffffd001`09193200 fffff801`7313cf63 : ffffe000`9feab378 00000000`00000000 ffffe000`9f44b710 ffffd001`0918e000 : tcpip!FlReceiveNetBufferListChainCalloutRoutine+0x155
ffffd001`09193330 fffff800`3b89a076 : fffff800`3b899d30 ffffd001`09193450 ffffe000`a01b1410 00000000`00000000 : nt!KeExpandKernelStackAndCalloutInternal+0xf3
ffffd001`09193420 fffff800`3b051a53 : 00000000`00000000 ffffd001`09193501 00000000`00000025 00000000`00000000 : tcpip!FlReceiveNetBufferListChain+0xb6
ffffd001`091934a0 fffff800`3b051e7f : 00000000`00000001 fffff800`3b050008 00000000`00000000 ffffd001`00000025 : NDIS!ndisMIndicateNetBufferListsToOpen+0x123
ffffd001`09193560 fffff800`3b052094 : ffffe000`9f4201a0 00000000`00000001 00000000`00312174 00000000`00000000 : NDIS!ndisMTopReceiveNetBufferLists+0x22f
ffffd001`091935f0 fffff800`3c005a1c : ffffe000`9f8af010 ffffe000`9f8af010 ffffd001`00000001 ffffd001`09193868 : NDIS!NdisMIndicateReceiveNetBufferLists+0x114
ffffd001`091937e0 fffff800`3c003249 : ffffe000`00000025 ffffe000`a0f7bd10 00000000`0000001b ffffe000`a11f0030 : netkvm!RxDPCWorkBody+0xf0 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-common.cpp @ 1658]
ffffd001`09193860 fffff800`3c00e2d0 : ffffe000`9f8af010 ffffd001`09193969 00000000`00000000 00000000`00000001 : netkvm!ParaNdis_DPCWorkBody+0xbd [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-common.cpp @ 1700]
ffffd001`09193890 fffff800`3b053e12 : 00000000`00000001 fffff801`731ba088 ffffd001`09193878 ffffd001`091937d0 : netkvm!MiniportMSIInterruptDpc+0x2c [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\wlh\parandis6-impl.cpp @ 399]
ffffd001`091938f0 fffff801`7310f4d0 : 00000000`00000000 ffffd001`09193c80 ffffe000`9f7e38e0 ffffd001`09193b60 : NDIS!ndisInterruptDpc+0x1a3
ffffd001`091939d0 fffff801`7310e817 : ffffe000`9f039800 ffffe000`9f039880 00000000`00000000 ffffd001`00000001 : nt!KiExecuteAllDpcs+0x1b0
ffffd001`09193b20 fffff801`731d53ea : ffffd001`0cdc0180 ffffd001`0cdc0180 ffffd001`0cdcc2c0 ffffe000`a1103080 : nt!KiRetireDpcList+0xd7
ffffd001`09193da0 00000000`00000000 : ffffd001`09194000 ffffd001`0918e000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x5a

2: kd> 3kv 123
Child-SP          RetAddr           : Args to Child                                                           : Call Site
ffffd001`091bee00 fffff801`730f0be2 : 00000000`00000002 00000000`00989680 ffffd001`091bef30 00000000`00000001 : nt!KxWaitForSpinLockAndAcquire+0x22
ffffd001`091bee30 fffff800`3c00942d : ffffe000`9f93201e 00000000`00000000 ffffe000`9f439980 00000000`00000000 : nt!KeAcquireSpinLockRaiseToDpc+0x32
(Inline Function) --------`-------- : --------`-------- --------`-------- --------`-------- --------`-------- : netkvm!CNdisSpinLock::Lock+0xa (Inline Function @ fffff800`3c00942d) [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-util.h @ 71]
(Inline Function) --------`-------- : --------`-------- --------`-------- --------`-------- --------`-------- : netkvm!CLockedContext<CNdisSpinLock>::{ctor}+0xa (Inline Function @ fffff800`3c00942d) [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-util.h @ 90]
(Inline Function) --------`-------- : --------`-------- --------`-------- --------`-------- --------`-------- : netkvm!CParaNdisTX::DoWithTXLock+0xa (Inline Function @ fffff800`3c00942d) [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.h @ 196]
ffffd001`091bee60 fffff800`3c009b78 : 00000000`00000001 ffffe000`9f5e5cc0 ffffe000`9fd32c60 00000000`00000000 : netkvm!CParaNdisTX::NBLMappingDone+0x25 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 310]
ffffd001`091bee90 fffff801`73019a37 : 00000000`00000018 ffffe000`9f5f9ed8 ffffe000`9f5f9ea0 ffffe000`9f5f9ea0 : netkvm!CNBL::RegisterMappedNB+0x6c [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 77]
ffffd001`091beec0 fffff800`3b058e82 : ffffe000`9f5f9ea0 ffffe000`9f420050 ffffe000`9f5f9ea0 ffffe000`9f5f9ee0 : hal!HalBuildScatterGatherListV2+0x207
ffffd001`091bef60 fffff800`3c009d46 : 00000000`00000000 fffff801`731460ca ffffe000`9ee9ab10 00000000`00000100 : NDIS!NdisMAllocateNetBufferSGList+0x1a2
ffffd001`091bf020 fffff800`3c00871e : 00000000`00000000 00000000`00000001 ffffe000`9f4201a0 fffff800`3c0096ec : netkvm!CNB::ScheduleBuildSGListForTx+0x2e [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 650]
(Inline Function) --------`-------- : --------`-------- --------`-------- --------`-------- --------`-------- : netkvm!CNBL::StartMapping::__l6::<lambda_ea34f6eaf6f02c2b80267054dd87e843>::operator()+0x8 (Inline Function @ fffff800`3c00871e) [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 240]
ffffd001`091bf060 fffff800`3c00a243 : ffffe000`9f5e5c02 ffffe000`9f5e5cc0 fffff800`3c013fb0 ffffe000`9f5f9c70 : netkvm!CNdisList<CNB,CRawAccess,CNonCountingObject>::ForEachDetached<<lambda_ea34f6eaf6f02c2b80267054dd87e843> >+0x3a [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-util.h @ 241]
ffffd001`091bf090 fffff800`3c009e51 : ffffe000`9f5e5cc0 ffffe000`9f865630 ffffe000`9f865630 00000000`00000001 : netkvm!CNBL::StartMapping+0x27 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 247]
ffffd001`091bf0c0 fffff800`3c00db9a : fffff800`3b4011a0 00000000`00000000 00000000`00000000 ffffe000`9fd34860 : netkvm!CParaNdisTX::Send+0xfd [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\common\parandis-tx.cpp @ 296]
ffffd001`091bf1c0 fffff800`3b056fb1 : 00000000`00000000 fffff800`3b899e4a ffffe000`9fdb0002 00000000`00000000 : netkvm!ParaNdis6_SendNetBufferLists+0x46 [c:\cygwin64\tmp\build\source\internal-kvm-guest-drivers-windows\netkvm\wlh\parandis6-driver.cpp @ 529]
ffffd001`091bf1f0 fffff800`3b88bee9 : ffffe000`9fdb5b00 ffffe000`9f5f9c70 00000000`00000000 00000000`00000000 : NDIS!NdisSendNetBufferLists+0x551
ffffd001`091bf3e0 fffff800`3b88ae63 : ffffe000`00000001 fffff801`73170001 00000000`0000003c ffffe000`a0fd5030 : tcpip!FlFastSendPackets+0xf1
ffffd001`091bf440 fffff800`3b88a98c : 00000000`00000000 ffffe000`00000014 ffffe000`9fe327e0 ffffe000`a0fd0000 : tcpip!IpNlpFastContinueSendDatagram+0x363
ffffd001`091bf520 fffff800`3b86e9a7 : 00000000`00000000 00000000`00000001 00000000`00000014 ffffe000`9fe327e0 : tcpip!IpNlpFastSendDatagram+0x308
ffffd001`091bf620 fffff800`3b8973f6 : 00000000`00000060 00000000`00000003 00000000`00000000 00000000`ffffffff : tcpip!TcpTcbHeaderSend+0x716
ffffd001`091bf8c0 fffff800`3b895ed2 : ffffe000`9f1c1a00 00000000`004d607e 00000000`00000004 00000000`00000000 : tcpip!TcpFlushDelay+0x156
ffffd001`091bf970 fffff801`7310ec38 : ffffd001`091bfc60 00000000`00000003 00000000`00000000 ffffd001`091ab180 : tcpip!TcpPeriodicTimeoutHandler+0x833
ffffd001`091bfb20 fffff801`731d53ea : ffffd001`091ab180 ffffd001`091ab180 ffffd001`091b72c0 ffffe000`a186d600 : nt!KiRetireDpcList+0x4f8
ffffd001`091bfda0 00000000`00000000 : ffffd001`091c0000 ffffd001`091ba000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x5a

Netkvm in vista/x86 from virtio-win-0.1-94.iso can't work

Hi Yan,

I tried to install the netkvm virtio driver to a 32bit windows server 2008 with virtio-win-0.1-94.iso, but it will yield code 10 error. virtio-win-0.1-81.iso works!

Best regards,
Ben

Installation

Hi there!

What's the requirements to install in win2008?
How to install the guest drivers?

Thanks.

Server 2008 R2 BSOD when installing viostor.sys

Got the following iso:
virtio-win-0.1-52.iso

and it bsods on install. The BSOD is flying by too quickly as the VM reboots. I can see that it is viostor.sys, though.

The block device is set up as
qemu-img create -f qcow2 test.img 128M

kvm -m 1024 -cdrom virtio-win-0.1-52.iso -drive file=win2008.img,if=ide -boot c -drive file=test.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -nographic -vnc :5

(the win2008.img was filled by an install from iso using ide drivers)

It is interesting that http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/ only links a pre whql driver suite.

NetKVM build problems

Build Env:
Win 2012 r2, DDK 7.1, WKD 8.1, VS 2013

I'm cloning repo, checkout tag mm131, run builadall.bat from powershell and VirtIO builds fine but NetKVM have errors, here is a build log: NetKVM-built.txt

First error is a CodeAnalize looking in a wrong path:

Could not find a part of the path 'C:\Users\Program Files (x86)\Windows Kits\8.1\CodeAnalysis\DriverRecommendedRules.ruleset'

Why he looked in Users?..

Second is compile errors:

The call to Slamcl returned with exit code:=1.
  This happened while compiling compile.cmd.
  The compile step failed for   'NetKVM' .
EXEC : Compile warning : ** Esp: EspCxxDrv failure (cfg): skipping function '__FallThrough'. [C:\Users\Administrator\Documents\git\kvm\NetKVM\netkvm.vcxproj]

EXEC : Compile warning : ** Esp: EspCxxDrv failure (cfg): skipping function '__FallThrough'. [C:\Users\Administrator\Documents\git\kvm\NetKVM\netkvm.vcxproj]

EXEC : Compile warning : C:\Program Files (x86)\Windows Kits\8.1\Include\shared\sal.h(2900) : fatal error C1001: An internal error has occurred in the compiler. [C:\Users\Administrator\Documents\git\kvm\NetKVM\netkvm.vcxproj]

  SDV exit code: 5
  SDV encountered errors when scanning the driver. Please ensure roletypes are present and/or consult SDV documentation.
C:\Program Files (x86)\Windows Kits\8.1\build\windowsdriver.Sdv.targets(65,9): error MSB3075: The command "staticdv.exe /check" exited with code 5. Please verify that you have sufficient rights to run this command. [C:\Users\Administrator\Documents\git\kvm\NetKVM\netkvm.vcxproj]
Done Building Project "C:\Users\Administrator\Documents\git\kvm\NetKVM\netkvm.vcxproj" (sdv target(s)) -- FAILED.

I now sure what wrong here.

P.S. Other drivers build fails too, but I guess source of a problem is same one.

When the number of queues less than number of vcpus, networking is not stable.

Hi Yan,

During the performance testing of multiqueue for NetKVM, I found that when the number of queues is less than number of vcpus (2 queue, 4 vcpu), the networking connection of VM will fail to work under a big pressure by receiving multiple netperf streams simultaneously. Meanwhile, under this case, disable virtio-net device or change the RSS related parameters of the virtio-net device will make device manager hang. I think this may be a bug.

VM OS: windows server 2008 R2 standard
virtio-driver: win7_amd64 netkvm built from the latest code.

Best regards,
Ben.

Vioserial & viorng build issue

Hello.

Build Env:
Win 2012 r2, DDK 7.1, WKD 8.1, VS 2013

I'm cloning repo, checkout tag mm131, run buildadd.bat
While building Vioserial & viorng I get a lot of errors. I attached logs of failed build:
viorng.txt
vioserial.txt

Could you please to look into them?

Network in WIndows Server 2008R2 guest drops during heavy host IO

We have an EL6.7 qemu/kvm host with several guests including a WIndows 2008R2 server. The host also runs our backups in the evenings and often the Windows guest will loose network connectivity and must be rebooted to regain it.

Host:
2.6.32-573.7.1.el6.x86_64
qemu-kvm-0.12.1.2-2.479.el6_7.2.x86_64

Guest:
Windows 2008R2
virtio-win-0.1.110

net-kvm: connection is failing when using bonded host networking with arp monitoring

Hello Yan,

I'm testing a setup on CentOS 6.4 which uses arp to monitor a network bond interface instead of miimon.
like:
...
IPADDR=172.16.93.6 # VMhost1f
BONDING_OPTS="mode=1 arp_interval=500 arp_validate=all arp_ip_target=172.16.93.10,172.16.93.20,172.16.93.23,172.16.93.29"
...

Then vlans are added to bond0 which are each added to it's own bridge. The network bridges are used for the virtual networking.

In the past I had used :
BONDING_OPTS="mode=1 miimon=100"

which is working fine but with arp monitor link failures beyond the directly connected switch will be detected.

On the host machine networking appears fine and the cluster manager does not detect any error's.

But the on the guest machine network starts with a lot of trouble. e.a. a slow connection and often failing until after a couple of minutes the guest networking fails completely.

Then after manual disabling the guest network interface and enabling it again the network connection is temporary restored until it fails again.

I have tested several net-kvm driver versions and none are working with this current setup.

Do you have a clue about what's happening?

Best regards,

Maurits van de Lande

virtio input driver

Hi,
Do you have plan to implement virtio input driver?
Thanks!

Question - undocumented NetKVM parameters / effects

Hello guys,

I've been googling a lot to find out how the following parameters affect latency.
Unfortunately, there is very little or no description of what they do and how they affect latency.

My goal is get low latency setup at the expense of higher CPU usage and lower throughput.
The question is, will the following values help me or not?

MergeableBuf = "Init.UseMergedBuffers" = True
Indirect = "Init.IndirectTx" = True
RxCapacity = "Init.MaxRxBuffers" = 1024 (default 256)
NumberOfHandledRXPackersInDPC = "TestOnly.RXThrottle" = 100 (default 1000)

Thank you very much

BSOD Balloon driver crashing Windows 7 64bit SP1 (fully updated).

I have tried to install 4 different versions:
0.1.102, 0.1.112, 0.1.113, 0.1.117

They all crash during install of the driver. I have to reboot in Safe Mode to uninstall the driver.

Also I noticed something odd about the virtio-win-0.1*.iso most are about 54Mbyte but version 0.1.102 is about 100Mbytes larger (153Mbyte).

When I mount the 54Mbyte isos on linux and use "du -sh /media/cdrom" it return 217Mbytes for the contents, but "df -h /media/cdrom" returns 55Mbytes. I don't understand how there could be 217Mbytes on the iso. They don't seem to be compressed.

I can still copy all the files off and get about the same amount of data. I am not sure if the iso have been truncated or if some of the files are damaged.

VM hangs while working with DPDK vhost-user when mrg_rxbuf=on

Hey folks,

I'm running an Win7 VM with virtio driver released in April 29th, 2014, with DPDK vhost-user (16.04) as the backend.

When mrg_rxbuf is turned off, everything works fine.
But the Win VM hangs when mrg_rxbuf=on: It happens when the first packet is sent to VM, and qemu CPU usage goes to 100%. No desc is handled by virtio-net from vhost observation.
This is always reproducable in my test.

The way I launch DPDK testpmd:

export RTE_SDK=<pwd>
make install T=x86_64-native-linuxapp-gcc -j32
./x86_64-native-linuxapp-gcc/app/testpmd -c 0xf -n 4 --socket-mem 4096,0 --vdev 'eth_vhost0,iface=/tmp/sock0,queues=1' -- -i --rxq=1 --txq=1 --nb-cores=1

After VM starts I type "start tx_first" which means testpmd will send packets to each port connects to it and then start forwarding, and the Win7 VM hangs right there.

I've tried a lot of Linux VMs with DPDK and never see anything like this.
Does anybody have a clue what might be the cause?

Thanks so much!

viostor win10 64-bit pro higher CPU/time in reading

hello,

we are testing a win10 VM with virtio 0.1.113. While all runs perfectly, it seems that we have performance regressions wrt win 8.1 64-bit pro. This is an early report, and it is rude, but it has prompted out by a simple "dir" command.

Additional info are provided at given links at end of report.

This is what I can recall to be relavant:

• host is an hp dl160gen9 with centos 7.x, virtualization is given by qemu-kvm 1.5.3-105.el7_2.3 (centos virt sig package). kvm-intel is the module.
• storage is local and is provided by soft raid5.
• both machines (win8.1 and win10) are fresh installs and have a 80GB virtio disk. raw storage on top of a thick LVM (same volume group). We have tried various storage strategies (from read cache to read/write cache with threads) and we have finally landed again to defaults.
• both machines have 2 vcpu. topology is 2 vcpu with 1 vcores each. CPU is the same of host.
  (config will show more cpu but desktop win versions limit available cpus to 2 sockets).

What we see is an higher time and CPU usage when accessing disk in read (write actually not tested yet). In order to have an idea of what happens, we have fired up a power-shell on both machines. The issued cmd is:

cd c:\windows\system32
Measure-Command {dir}

both win 8.1 and win 10 have really comparable system32 sizes but win 10 requires 350ms vs 230 of win8.1. test has been repeated (by hand) 20 times given consistent results.
At the same time the total cpu usage remains around 20% on win 8.1, while it jump up to 30% on win 10.

Is this to be expected at the given devel stage, or can we provide additional info on the topic (any suggestion is welcome)?

bye,
M

win 8.1 full config
win 10 full config

Windows 8.1 "couldn't automatically bind the IP protocol stack to the network adapter"

Sometime in the near past my Windows 8.1 VM had a hiccup (repair was run on the drive), and now I cannot get the virtio drivers to behave themselves.

I've removed and re-added the network configuration via the guest setup on the host (changed the libvirt XML). I've removed and re-added the NetKVM drivers on the guest.

The adapter appears to be working. No network protocols are working.

I have a Windows 7 VM that is working without issue, so I feel reasonably certain it's not a Network configuration problem on the host.

Any suggestions beyond the normal "Windows 8.1 network broken? Reinstall!" option?

blnsvr.exe doesn't work well on Windows 2008 32bit with RAM more than 2GB

Balloon service returns total_mem=2047 on 32bit systems with more than 2GB RAM:

balloon: actual=10140 max_mem=10240 total_mem=2047 free_mem=2047 mem_swapped_in=0 mem_swapped_out=0 major_page_faults=0 minor_page_faults=25 last_update=1366968865

Balloon memory statistics always are not available

@YanVugenfirer,

I ran into a trouble, when I had enabled the Balloon memory statistics via qmq command,

{"execute": "qom-set","arguments": { "path": "/machine/peripheral/balloon0","property": "guest-stats-polling-interval", "value": 2 } }

but I always get a empty data on balloon memory statistics.

{"execute": "qom-get","arguments": { "path": "/machine/peripheral/balloon0","property": "guest-stats" } }
{"return": {"stats": {"stat-swap-out": -1, "stat-free-memory": -1, "stat-minor-faults": -1, "stat-major-faults": -1, "stat-total-memory": -1, "stat-swap-in": -1}, "last-update": 0}}

my environment is

• qemu-kvm 2.3.0
• virt-win-0.1.102.iso
• windows 2008R2 64 bit

I tried to debug it with gdb, I found that the virtio_balloon_receive_stats function inside qemu/hw/virtio/virtio-balloon.c is not called, it seems the windows virtio balloon driver does not kick off the statistics queue of virio balloon device.

Can you give me a hint about the issue? Need I to debug the windows guest driver?

Thanks
Wei

Bump version number in vioscsi/buildAll.bat when doing a release

Would it be possible to occasionally update the RHEL_RELEASE_VERSION, BUILD_MAJOR_VERSION, BUILD_MINOR_VERSION in vioscsi/buildAll.bat when doing a release?

The source, without any special environment variables, appears to build version "62.61.101.58000". The latest binary releases from this location:
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/

..have version "62.71.104.10000".

I guess in your usual release process you set RHEL_RELEASE_VERSION etc. in the environment before building?

It's not necessary to update the version very often, just every release would be ok, so we can translate from binary version to approximate source version.

VirtIO Ethernet Adapter becomes slow after some time

I have a number of VMs running on a couple of Dell servers (lots of RAM 8 cores etc). Running a mixture of Windows and Linux VMs. The hosts are running Fedora 19 simple setup using libvirt.

The Windows guest which is currently a mix of Windows 7 Enterprise 64bit and Windows Server 2008R2 all seem to suffer from an issue where after a while (about a week or so) the networking become very slow, I think it is dependant on how much traffic has been passed. Rebooting the guest fixes the issue for a while. I have not been able to nail down the issue. After the start it all runs fine and nice and fast. When I say slow it is just about unusable, RDPing into the guests (how the users use access the machines)

When we had XP guests they did not suffer from this issue nor do any of the Linux guests.

The drivers before 0.1-52 seems to be not less effected by this.

All guests use bridge networking. We are using the latest drivers from either http://alt.fedoraproject.org/pub/alt/virtio-win/stable/ or http://www.spice-space.org/download.html.

I probably have not provided a enough information here so please let me know what I can provide.

BSOD on boot in NDIS.sys

Several times I've seen a crash in NDIS.sys at boot - before the login screen is even shown. I have to assume this is the VirtIO Ethernet driver. I believe I also saw a similar BSOD when I first tried to load the driver.

Unfortunately, for some reason, no minidump is generated, even though the system is configured to do so. Also, this bug is not easily reproduced. I'll leave this bug open as a reminder, and a place to record any findings.

The windows2008r2/win7 guest hang when it use vhost-user backend nic on some new cpu model

I start windows2008r2/win7 guest which use vhost-user backend nic on the fllowing cpu model.
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
stepping : 2
microcode : 0x2d

The guest hang when it start windows.But windows xp/2000/2003 guest can start normaly.
The qemu command line like this:
qemu-system-x86_64 -name instance-0000006f_test -machine pc-i440fx-2.5,accel=kvm,usb=off -cpu Haswell-noTSX,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme,+kvm_pv_eoi -m 8192 -object memory-backend-file,id=mem,size=8192M,mem-path=/dev/hugepages,share=on -numa node,memdev=mem -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 06302b6a-525f-451a-bcf9-188b7240912c -no-user-config -nodefaults -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/home/liuyb/win7.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -chardev socket,id=charnet0,path=/opt/network/ovdk/bin/vhost.sock -netdev type=vhost-user,id=hostnet0,chardev=charnet0,vhostforce -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:e7:bf:3f,bus=pci.0,addr=0x3 -device usb-tablet,id=input0 -vnc 0.0.0.0:1 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on

And in some old cpu model, the 2008r2/win7 guest also start normaly.
test cpu model:
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x417

vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E7-4860 v2 @ 2.60GHz
stepping : 7
microcode : 0x70a

If the guest don't have nic,it can start.So I think the error has the relationship with the nic.After some tests,I found that the guest hang because bit28(VIRTIO_RING_F_INDIRECT_DESC) of the host_feature of virito was set 0.When the bit is set 1，the guest starts normaly.
But the old cpu model don't have this problem,whether the VIRTIO_RING_F_INDIRECT_DESC bit is set 0 or not. So I wonder if the netkvm driver of the 2008r2/win7 has the compatibility problem with the new cpu model.

win2008r2 amd64 crash when using same backingfile

Environment:

labuser@os-cloud-2:~$ uname -a
Linux os-cloud-2 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

labuser@os-cloud-2:~$ kvm --version
QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard

Multiple version drivers (up to build-48) from:
http://people.redhat.com/vrozenfe/

Openstack Folsom is used for deployment

libvirt:
cache=none
image=qcow2

I've been tracking down an issue that when I deploy multiple win2k8r2 instances that end up using the same backingfile (at it seems this is the issue) I end up with a BSOD for every instance except the first. This happens often directly when applying the new settings to the generalized instance and sometimes to a running instance. (DRIVER_IRQL_NOT_LESS_OR_EQUAL)

If I make the backingfile unique per instance the problem seems to go away, but needless to say that is not a situation I would like to maintain.

I can provide a minidump and even provide access to the environment if that helps tracking down the issue.

viostor bad write performance compared to older version

When using version 1.094, 1.02, or 1.110 of viostor.sys I get less than half the write performance compared to using version 1.074 and version 1.81.

I'm Windows 2012 R2 and Windows 8.1 instances with a host using qemu-kvm version 1.5.3 and a ceph version 0.94.3 storage backend. I have cache=writeback and rbd cache enabled as well.

When using 1.74 of viostor.sys I get the following numbers using crystaldiskmark

Test	Read MB/s	Write MB/s
Seq Q32T1	716.9	120.9
4K Q32T1	58.04	9.606
Seq	321.0	112.8
4K	5.697	11.88

When using 1.110 I get

Test	Read MB/s	Write MB/s
Seq Q32T1	820.4	41.78
4K Q32T1	64.08	0.543
Seq	448.3	38.80
4K	7.474	0.109

Version 1.094 and 1.102 have similar write numbers to 1.110

Balloon driver preventing Windows 7 guest from shutting down

My Windows 7 Utlimate (64-bit) guest hangs at the "(spinner) Shutting down..." screen after clicking Start -> Shutdown.

Uninstalling the Balloon driver allows the guest to fully shut down.

Host:

Component	Version
OS	CentOS 7 x64
Kernel	3.10.0-123.el7.x86_64
qemu.x86_64	2:2.0.0-1.el7.3
virt-manager	0.10.0-20.el7

Guest:

Component	Version
OS	Windows 7 Ultimate (64-bit)
CPU	QEMU Virtual CPU version 1.5.3 (2 processors)

virtio-win-0.1-94 drivers installed:
VirtIO SCSI: viostor.sys 61.71.104.9400
VirtIO-Serial: vioser.sys 61.71.104.9400
VirtIO Balloon: balloon.sys 61.71.104.9400
VirtIO Ethernet: netkvm.sys 61.71.104.9400

Windows 10 1511 x64 install to vioscsi-connected disk hangs

The Windows 10 1511 x64 installer stops at "Getting files ready for installation" when attempting to install to a virtio-scsi disk using the vioscsi driver from virtio-win 0.1.112-1 or 0.1.113-1 as distributed by Fedora. CPU and disk activity (as seen by the host) stops and the installer never shows any progress beyond 4-6%, though I can move the mouse and cancel the installation.

This is a regression from virtio-win 0.1.110-2 -- the Windows 8.1 drivers from that build work fine. The host is running Linux kernel 4.1.20 and the VM is running in QEMU 2.5.1 using KVM.

Possible data structure corruption

We saw a crash that seems to happen when pausing the NetKvm adapter. We recovered the following 2 stacks from the dump.

00 fffff802`4a6a3c08 fffff802`4903c1c2 nt!KeBugCheckEx 
01 fffff802`4a6a3c10 fffff802`49232e4d hal!HalBugCheckSystem+0x7e 
02 fffff802`4a6a3c50 fffff802`4903cfa1 nt!WheaReportHwError+0x22d 
03 fffff802`4a6a3cb0 fffff802`49256c20 hal!HalHandleNMI+0xfe 
04 fffff802`4a6a3ce0 fffff802`491cc7c2 nt!KiProcessNMI+0x150 
05 fffff802`4a6a3d30 fffff802`491cc636 nt!KxNmiInterrupt+0x82 
06 fffff802`4a6a3e70 fffff802`49101d6e nt!KiNmiInterrupt+0x176 
07 fffff802`4a698950 fffff800`57bdd768 nt!KxWaitForSpinLockAndAcquire+0x22 
08 fffff802`4a698980 fffff800`57bde585 netkvm!CNdisList<CNBL,CRawAccess,CNonCountingObject>::ForEachPrepareIf<<lambda_6e3a6aeb098631fcc79aaecc43ea142b>,<lambda_0fb1256e1da6df1a035ab89e05289ff7>,<lambda_2e9bd86eeab3a657911ddcd0e23da5de> >+0x4 
09 fffff802`4a6989c0 fffff800`57bd8061 netkvm!CNBL::ParseBuffers+0xbd 
0a fffff802`4a698a70 fffff800`57be351c netkvm!ParaNdis_CleanupContext+0x71 
0b fffff802`4a698aa0 fffff800`55ea8e12 netkvm!ParaNdis6_SendPauseRestart+0x50 
0c fffff802`4a698b00 fffff802`490b2f10 NDIS!ndisInterruptDpc+0x1a3 
0d fffff802`4a698be0 fffff802`490b2257 nt!KiExecuteAllDpcs+0x1b0 
0e fffff802`4a698d30 fffff802`491c63d5 nt!KiRetireDpcList+0xd7

00 ffffd001`5abf8fe0 fffff802`49101d32 nt!KxWaitForSpinLockAndAcquire+0x1f 
01 ffffd001`5abf9010 fffff800`57bde711 nt!KeAcquireSpinLockRaiseToDpc+0x32 
02 ffffd001`5abf9040 fffff800`57bdeecc netkvm!CNBL::ParseOffloads+0xc5 
03 ffffd001`5abf9070 fffff802`4900ba37 netkvm!CParaNdisTX::SendMapped+0x3c 
04 ffffd001`5abf90a0 fffff800`55eade82 hal!HalBuildScatterGatherListV2+0x207 
05 ffffd001`5abf9140 fffff800`57bdf09a NDIS!NdisMAllocateNetBufferSGList+0x1a2 
06 (Inline Function) --------`-------- netkvm!RtlFailFast+0x2 
07 (Inline Function) --------`-------- netkvm!FatalListEntryError+0x2 
08 (Inline Function) --------`-------- netkvm!InsertHeadList+0x10c 
09 (Inline Function) --------`-------- netkvm!CNdisList<CNBL,CRawAccess,CNonCountingObject>::Push+0x120 
0a ffffd001`5abf9200 fffff800`57bdda02 netkvm!CParaNdisTX::SendMapped+0x20a 
0b (Inline Function) --------`-------- netkvm!CNBL::ParseOffloads::__l39::<lambda_45c6048e0eee80e44000724f00745ebe>::operator()+0x18 
0c ffffd001`5abf9240 fffff800`57bdf58f netkvm!CNBL::ParseCSO<<lambda_07bb9e4d8a255eab68dc9a6db8158716>,<lambda_8edd56c1927263d1d00c45709877ef5c>,<lambda_45c6048e0eee80e44000724f00745ebe> >+0x2a 
0d ffffd001`5abf9270 fffff800`57bdf1a5 netkvm!CTXVirtQueue::Create+0x43 
0e ffffd001`5abf92a0 fffff800`57be2dce netkvm!CNB::SetupLSO+0xc1 

I think the cause is that m_SendList uses the CRawAccess strategy and there's a race between Remove_LockLess in RemoveAllNonWaitingNBLs and Push in PushMappedNBL. This causes the FatalListEntryError I believe. Using RemoveHeadList instead of RemoveEntryList may be threadsafe. Otherwise I was thinking the m_SendList may need a new barrier to prevent adding new entries when pausing the adapter.

Server 2012R2 network dropout during high guest CPU usage

Ubuntu 14.04, kernel 3.15.1 mainline, Qemu 2.0, OpenVSwitch 2.0.1
Virtio drivers 0.1-81 and 0.1-74

<interface type='network'>
  <mac address='52:54:00:81:f4:46'/>
  <source network='ovs-network' portgroup='vlan-24'/>
  <model type='virtio'/>
  <driver name='vhost' txmode='iothread' ioeventfd='on' event_idx='on' queues='5'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

I've replicated the issue with two Server 2012R2 guests, both are 32GB and 8vCPU. When under moderate to high CPU load (> 50% ish) they start dropping packets for 3-10 seconds at a time. These servers were both running as remote desktop servers and the problem causes all of the users to be disconnected completely from the server. Running a ping in the background shows ICMP drops for 3-10 seconds during the disconnections. During testing the issue never came up presumably because the CPU usage was low. Network usage appears to have no relation to the issue and I've done large sustained transfers (>2Gbit/s) with no issue.

Changing the adaptor to e1000 fixes the issue. I've also tried disabling MQ, vhost, ioeventfd and event_idx but the issue still occurs. The same drivers on 2008R2 perform flawlessly. All guest based adaptor settings have been left as default.

If you need me to do any further testing just let me know. Happy to help.
Thanks

Windows Server 2012 BSOD/Reboot scan for hardware changes in device manager

Greetings,

I have discovered that when using virtio-win-0.1-59 drivers on Windows Server 2012, if you open the device manager and scan for hardware changes it causes the instance to BSOD reboot unexpectedly. Is this a known issue? If any more information would be helpful, needed or required please let me know and I will obtain and provide details.

Thanks in advance.

Windows Server 2012 R2 does not pick up hard disks.

Hello,

I'm an early adopter customer at Microsoft, we have been given access to an early preview build of Server 2012 R2 and I decided to load it up on Ubuntu and KVM. After loading the SCSI driver the disks do not appear. I am using virtio-win-0.1-59.iso on an update Ubuntu 12.04 server. Please let me know if you need anything else from me.

More information needed

Hello,

it would be great if you could provide a README.md in this repository.

Are drivers these supposed to be installed on the guest?

Is Windows XP professional supported?

Greetings

win2008R2 : virtio-blk : bsod on boot disk live block_resize

Hi,
I'm trying to resize (extend) a boot disk (c:) on win2008R2 with virtio-blk disk, with qmp block_resize.
qemu 1.4 / drivers build 52

I got bsod, I can reproduce 100%.

It's working fine with resize of a non boot device (d:).
It's working fine with virtio-iscsi disk boot device.

New version of NetKVM has no RSS and related parameters anymore?

Hi, Yan

I can find RSS parameter when I installed the virtio-net from virtio-win-0.1-81.iso, but I can't find it in 0.1-94 version, does the new version support RSS, if yes, how to enable and disable it?

Best regards,
Ben.

Possible integer overflow in debug tool

Hi, We are the “Yundun Xianzhi Vulnerabilities Platform“ which is under the Aliyun of Alibaba. One of our whitehats has just reported an integer overflow vulnerability of KVM WindowsGuestDrivers of VirtIO. Here are the details about this problem provided by the whitehat.

1. Version

The version is stable_single_port_virtio-serial rhel60

1. Related Source code

The function in kvm-guest-drivers-windows/NetKVM/DebugTools/VirtioConsoleSimulation/engine.c void SetMacAddresses(int num) has integer overflow problem, the analyze are as follows:

// 函数接受输入参数num
EXTERN_C void SetMacAddresses(int num)
{
UCHAR _mac[10] = {0};
struct virtio_net_ctrl_mac *pMacCtrl;
// 通过对num进行计算，得到mcSize值用于分配内存空间
USHORT mcSize = sizeof(uint32_t) + num * ETH_ALEN;
// 在进行malloc分配空间的时候，没有对num和mcSize进行判断，会发生整数溢出
UCHAR *multicasts = (UCHAR *)malloc(mcSize);
....
// 后续在使用num值来访问multicasts对应的内存空间，导致访存错误！
for (i = 0; i < num; ++i)
{
UCHAR *p = &pMacCtrl->macs[i][0];

1. Trigger

VirtioConsoleSimulation is an independent project of VirtIO NetKVM. This vulnerability can be triggered by the following code:

ConsoleSim.cpp : _tmain -->
testCommands.cpp : RunScript -->
testCommands.cpp : tScriptState::Run -->
testCommands.cpp : tScriptState::ExecuteCommand -->
engine.c : SetMacAddresses(int num)

The folloing command can trigger this:

ConsoleSim.exe run.txt
The content in run.txt:

prepare
control.mac 357913946
end

BALLOON install problems on Vista and WS 2008 original

I am unable to install the balloon.sys driver automatically with an unattended setup file on plain Windows VISTA and Windows Server 2008 (original) with no service packs. I also receive errors when attempting to manually install the driver using pnputil.

Test guest: Windows Server 2008 (original, no SP)
Driver Source: virtio-win-0.1-81.iso

error log during unattended setup:

Errors when installing manually:

win2008R2 bsod virtio-win-prewhql-0.1-25 (qemu 0.15)

Hi, I got a 2 bsod today with build25

Problem signature:
Problem Event Name: BlueScreen
OS Version: 6.1.7601.2.1.0.272.7
Locale ID: 1036

Additional information about the problem:
BCCode: d1
BCP1: 0000000000000000
BCP2: 0000000000000002
BCP3: 0000000000000008
BCP4: 0000000000000000
OS Version: 6_1_7601
Service Pack: 1_0
Product: 272_3

DRIVER_IRQL_NOT_LESS_OR_EQUAL
.....
*** storport.sys - Address FFFFF880012170E9 base at FFFFF88001216000, DateStamp 4ce7a456

guest :

• win2008R2 + sql 2008R2
• 24cpus
• 30GB ram
• 2 virtios disk,cache=writeback

Host:

• Quad amd opteron 6172 (48cores)
  -250GB ram
  with qemu 0.15 ,

Crash occur around 5 min after windows boot.

I can provide the minidump. (I don't have the full dump)

I'll try to test it with last qemu-kvm git tommorow on a test server with the same cloned guest.

vioscsi loading stucks with uas device on scsi-block

When trying to load the vioscsi in Windows 10 installation, the guest stucks at the above stage. It does not freeze though, I can still move the cursor and the progress bar is still going back and forth.

Then when I try to kill it with ^C, the process turns into some kind of zombie as shown. You can see that it turned into some "qemu-system-x86" which doesn't really exist.

The device is a first gen Intel X25-M SSD connected to USB 3 through a StarTech UAS adapter:
http://ark.intel.com/products/56604/Intel-SSD-X25-M-Series-80GB-2_5in-SATA-3Gbs-50nm-MLC
http://www.startech.com/HDD/Adapters/USB-3-SATA-adapter-cable-with-UASP~USB3S2SAT3CB

I can load vioscsi successfully in the guest if I use the "u" quirk of "usb-storage" in host so that the device does not bind to the uas driver. scsi-hd and viostor works on uas too, just not scsi-block. Also the device never showed any problem when being used physically under Windows or Linux.

I tried that on a Windows Server 2012 R2 (Server version of Windows 8.1) ISO as well, same issue occured.

Feel free to let me know if you need some more other info.

Updating balloon.sys to 0.1.96 results in BSOD crash

I updated my Win 2008R2 system's balloon.sys to 0.1.96 an immediately got a BSOD crash in balloon.sys. STOP code 0x0000007e and on all subsequent boots. Disabling the memory balloon device in libvirt for the guest allowed it to boot.

Host is Scientific Linux 6.6, qemu-kvm-0.12.1.2-2.448.el6_6.4.x86_64.

How to build for windows server 2008?

I build with winddk 7600.16385.1, but encountered 'DDK_TARGET_OS defined as "WinLH" (unsupported)" error, how should I do to build out the binary?

Big problems with tcp offload

I use KVM in my company with a mix Linux/WIndows.

I use them with vhost_net, bridge and/or macvtap.

Problems com with macvtap on Windows.
without any management of tcp offload :

1. Windows reject any packet send from another vm on the same host (and in macvtap too). (can be correct by a tricky rule in iptables... but it's quite awful
2. More painful, when GRO is activated on host, ALL packets are dropped by windows...

driver bluescreens in R2 VM

We are running an Ubuntu-based Linux cluster using qemu/KVM to create a virtualized environment. Guest OS is Win2k8 R2 SP1 x64. Our system has dual redundant storage controllers and the Linux hypervisors are configured for multipathed IO. When we run failover testing on the storage controllers the HV appears to be fine but we are getting occasional bluescreens from the VirtIO storage driver in the guest.

DRIVER_IRQL_NOT_LESS_OR_EQUAL
STOP: 0xD1 (0x168, 0x2, 0x0, 0xXFFFFF88000FDA1D2)
viostor.sys

Driver version is 61.63.103.2200 pulled from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/.

Is there any driver update which might address this issue, or is anyone interested in trying to debug the problem? We can reproduce the issue as needed and provide memory dumps and other debug information.

Thanks!

Server 2008 R2 BSOD when installing viostor.sys

Instructions for w2k needed

I cannot find instructions or pointers to documentation for compiling for windows 2000. Firstly what version of ddk is needed? Where can I find it? Alternately are there compiled binaries available?

Is cache=writeback safe with viostor driver (is wce exposed?)

Hi,
not an issue, but just one question:

Can we safely use cache=writeback with viostor driver ?
(by safely, I mean data loss but no data corruption if host have a powerfailure).

Is wce flag exposed to windows (like virtio on linux) ? Could ntfs manage flushs correctly ? (like barrier on linux ?)

Best regards,

Alexandre Derumier

Poor performance with vioscsi and scsi-block (AHCI SSD)

For some reason there seems to be a weird bottleneck on its performance when vioscsi works with scsi-block (but not scsi-hd).

The passthrough'd storage is an Intel 530 240GB SATA SSD on Intel H87 AHCI (and obviously the passthrough'd SCSI layer is the SATL provided by libata-scsi). qemu 2.5.0 / linux 4.5.1 / Windows 10 Build 10586. Tested with both drivers in virtio-win-0.1.117.iso and virtio-win-0.1.102.iso

qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=disks/win10__.qcow2,format=qcow2,cache=none,aio=native -drive file=/dev/sdb,format=raw,cache=none,aio=native,if=none,id=bench -device virtio-scsi-pci -device scsi-block,drive=bench:

qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=disks/win10__.qcow2,format=qcow2,cache=none,aio=native -drive file=/dev/sdb,format=raw,cache=none,aio=native,if=none,id=bench -device virtio-scsi-pci -device scsi-hd,drive=bench:

qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=disks/win10__.qcow2,format=qcow2,cache=none,aio=native -drive file=/dev/sdb,format=raw,cache=none,aio=native,if=virtio:

qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=disks/win10__.qcow2,format=qcow2,cache=none,aio=native -drive file=/dev/sdb,format=raw,cache=none,aio=native,if=none,id=bench -device virtio-blk-pci,drive=bench,scsi=on:

(Note: I wanted to see if enabling SCSI passthrough on virtio-blk-pci would trigger the same issue. However, scsi=on seems to be a no-op when the guest is Windows, since viostor does not work the same way as virtio-blk in Linux. Is it a bug or for some reason intended btw?)

DRIVER_POWER_STATE_FAILURE (9f) in Balloon driver

I'm guessing this happened when the VM tried to go to sleep.
(Err.. "Sleep" is disabled in the start menu... so maybe it was just random)

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: fffffa8003eaba10, Physical Device Object of the stack
Arg3: fffff80000b9c518, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: fffffa8004cbb250, The blocked IRP

Debugging Details:
------------------


DRVPOWERSTATE_SUBCODE:  3

IMAGE_NAME:  pci.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4ce7928f

MODULE_NAME: pci

FAULTING_MODULE: fffff88000fb9000 pci

DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

BUGCHECK_STR:  0x9F

PROCESS_NAME:  System

CURRENT_IRQL:  2

ANALYSIS_VERSION: 6.3.9600.17298 (debuggers(dbg).141024-1500) amd64fre

DPC_STACK_BASE:  FFFFF80000BA2FB0

STACK_TEXT:  
fffff800`00b9c4c8 fffff800`029428d2 : 00000000`0000009f 00000000`00000003 fffffa80`03eaba10 fffff800`00b9c518 : nt!KeBugCheckEx
fffff800`00b9c4d0 fffff800`028dd85c : fffff800`00b9c600 fffff800`00b9c600 00000000`00000000 00000000`00000001 : nt! ?? ::FNODOBFM::`string'+0x33af0
fffff800`00b9c570 fffff800`028dd6f6 : fffff800`02a83140 00000000`00010374 00000000`00000000 00000000`00000000 : nt!KiProcessTimerDpcTable+0x6c
fffff800`00b9c5e0 fffff800`028dd5de : 00000002`6a97dafc fffff800`00b9cc58 00000000`00010374 fffff800`02a51108 : nt!KiProcessExpiredTimerList+0xc6
fffff800`00b9cc30 fffff800`028dd3c7 : 00000000`dd873ec1 00000000`00010374 00000000`dd873ee4 00000000`00000074 : nt!KiTimerExpiration+0x1be
fffff800`00b9ccd0 fffff800`028ca8ca : fffff800`02a4de80 fffff800`02a5bcc0 00000000`00000000 fffff880`0360fdb0 : nt!KiRetireDpcList+0x277
fffff800`00b9cd80 00000000`00000000 : fffff800`00b9d000 fffff800`00b97000 fffff800`00b9cd40 00000000`00000000 : nt!KiIdleLoop+0x5a


STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

IMAGE_VERSION:  6.1.7601.17514

FAILURE_BUCKET_ID:  X64_0x9F_3_POWER_DOWN_balloon_IMAGE_pci.sys

BUCKET_ID:  X64_0x9F_3_POWER_DOWN_balloon_IMAGE_pci.sys

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:x64_0x9f_3_power_down_balloon_image_pci.sys

FAILURE_ID_HASH:  {e131123e-4350-338f-3601-9b355fe105a4}

Followup: MachineOwner
---------

0: kd> dt nt!TRIAGE_9F_POWER
Symbol nt!TRIAGE_9F_POWER not found.
0: kd> !irp fffffa8004cbb250
Irp is active with 4 stacks 3 is current (= 0xfffffa8004cbb3b0)
 No Mdl: No System Buffer: Thread 00000000:  Irp stack trace.  
     cmd  flg cl Device   File     Completion-Context
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
>[ 16, 2]   0 e1 fffffa80045b2e10 00000000 00000000-00000000    pending
          *** ERROR: Module load completed but symbols could not be loaded for balloon.sys
 \Driver\BALLOON
            Args: 00016600 00000001 00000004 00000006
 [  0, 0]   0  0 00000000 00000000 00000000-fffffa8004f871c0    

            Args: 00000000 00000000 00000000 00000000

windows gets low disk performances

Please, have a look at this.

Shortly: It's a post where I report about some tests conducted on kvm/virtualbox to better understand a poor disk performance demonstrated by windows VMs under KVM on Centos 7.2.

Used qemu-kvm is coming from centos virt sig, virtio is 0.1.117 and host kernel is latest stock.
Test is a basic iozone random-mix on small files.

I've seen kvm Windows guests provide poor performance in iozone random mix with 1 thread, so I've started performing some comparisons to understand where the flaw was.

As a summary: I've tested both a virtio scsi and an iscsi target (the latter is mounted from within the VM as additional storage and is NOT passed as libvirt storage). I've tested kvm VMs, both linux and Windows, plus a remote Windows workstation (for the iscsi target comparisons) along with a number of Virtual Box instances running on such workstation.

While Windows has good performances even on a remote iscsi targets either as host or Virtual Box Guest, in kvm only linux can provide acceptable thuroughput.

Windows in kvm "fails" both on vscsi or (local) iscsi targets.

Maybe I can use the post as a starting point to provide you more info and let me fix the issue. server fault community simply suggests to wait for the upcoming centos 7.3... while this can be a good advice IMHO it is a bit over-simplistic to classify the issue as "kvm+virtio sucks on centos 7.2".

thank you!

NetKVM driver fails to disable TCP/UDP checksum offloading for IPv6 when host lacks support

TCP and UDP communication over IPv6 fails on Windows guests using virtio-net when QEMU is using the userspace networking (slirp) backend. Adding debug printfs to the slirp code suggests that the guests' transmitted packets are being ignored because of incorrect checksums, and disabling TX checksum offload in the driver settings in Windows allows traffic to pass.

The slirp backend doesn't appear to support checksum offloading, and Linux guests disable checksum offloading accordingly (as verified with ethtool -k). A quick check of the NetKVM code suggests that the driver does the same thing -- but only for IPv4 (https://github.com/YanVugenfirer/kvm-guest-drivers-windows/blob/master/NetKVM/Common/ParaNdis-Common.cpp#L714); my uninformed guess is that NetKVM needs to disable checksum offloading for TCP/UDP over IPv6 here as well.

Tested most recently with a Windows 10 1511 x64 guest using NetKVM from virtio-win 0.1.113-1 as distributed by Fedora, running on QEMU built from commit 8b4aaba736e55c8ab6d71350f850a6642f0165b9 (after 2.6.0-rc1). I've had this problem in the past with Windows 7 guests and older versions of the IPv6 userspace networking patch, though.

VirtIO ethernet doesn't recognize new MAC

When I change the mac address (e.g. via 'virsh edit') and start the VM, the command 'ipconfig /all' in windows still prints the original MAC.

If I do the same with a linux host, the correct MAC is printed.

A workaround that helps is to change the device model (e.g. to e1000), boot windows, shutdown, set device model back to virtio, boot again. Just deleting the device in device manager (+rebooting or rescanning) doesn't seem to help.