Microsoft is now building Windows 10 and Windows Server for ARM64 machines. To successfully run these in qemu, virtio drivers are needed for the ARM64 platform.

https://github.com/virtio-win/kvm-guest-drivers-windows/issues/60 notes that "Gal is working on it". I didn't find his repo. So let's track progress here! @hammerg , @YanVugenfirer invited ;)

The Windows 10 ARM 64 went wrong like this : After the reboot , it went wrong like this :

I think this error is caused by the VirtIO drivers . I installed the VM using this method : 1.Make an iso image using uupdump 2.Make an empty image using command qemu-img create -f vpc Windows.vhd 80G 3.Boot and install the system qemu-system-aarch64 -M virt-2.11 -cpu host \ -smp cores=4,threads=1,sockets=1 \ -m 2G -device nec-usb-xhci \ -device usb-kbd -device usb-tablet \ -net user -net nic,model=virtio \ -pflash QEMU_EFI.img -pflash QEMU_VARS.img \ -device virtio-blk,drive=disk \ -drive if=none,id=disk,file=Windows.vhd \ -device usb-storage,drive=install \ -drive if=none,media=cdrom,id=install,file=Windows.iso \ -device usb-storage,id=drivers -drive if=none,id=drivers,file=fat:drivers \ -serial stdio -vnc :0 -device ramfb -enable-kvm the driver folder contains the virtio drivers like netkvm.inf vioster.inf,etc. the UEFI firmware are compiled from edk2-edk2-stable-202002 source code . 4. Install the drivers to let the PE recognize the disk . 5. Finish the installation and then reboot . 6. ERROR Host information Host : Raspberry Pi 4B 4G with Ubuntu 20.04 VirtIO drivers version : 0.17.3 Guest version : Windows 10 ARM64 Build 19041&18362

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.

As probably well known virtio-fs on a Win10(20H2) Windows guest (and maybe other versions too) is unusable for some users.

The way this problem manifests at first is that a user is able to create/delete files or directories on a drive mapped through virtio-fs, but then he cannot modify them in any way (where in the case of a directory this means to add any file to it or remove it).

On a first look this problem appears of the same nature of few others that have been affecting some WinFsp filesystems, but on a further analysis it actually seems to be specific to the virtio-fs driver which, before restart, returns VirtFs->LocalUid == VirtFs->LocalGid == 0 (or better most probably does so).

Once the virtio FS service is restarted (after logging in into the VM at least) the returned uid/gid are correct and the file permissions correctly mapped to those of the underlying linux host filesystem.

A more complete description of this problem is found in virtio-fs with a win10 QEMU guest and WinFsp

I'm available to perform some testing or answer other questions if needed.

Thank you.

Edit: I wonder if the virtio-fs service should be started after some other windows service that I'm not aware of...

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.

I know I have raised this before, and to work around the problem I obtained a personal driver signing certificate so I could continue working on this project, but I am nearing release and I would like the Red Hat signed build to be available before I open my code up to the public.

The project that uses this is "Looking Glass", it has garnered an enormous amount of publicity and hundreds of users are extremely excited to use it, but without the ivshmem driver it will not work. This project bridges the last hurdle in consumer space VM integration with full 3D Acceleration.

https://forum.level1techs.com/t/a-little-teaser-of-what-is-to-come https://www.youtube.com/watch?v=tHv9qh2F3NU

Once all our ducks are all lined up I will be publishing the source under GPL 2.0 on GitHub, I don't want people to grab this and be disappointed that it doesn't function yet.

Hello,

I've been experiencing connectivity loss issues with what seems to be every version of the Windows Virtio NetKVM driver on Windows 10. This is my current configuration:

Host OS: Ubuntu 18.04 Guest OS: Windows 10 1903 Kernel: Linux 4.15.0-36-generic x86_64 QEMU-KVM Version: 2.11+dfsg-1ubuntu7.6 NetKVM Versions: 0.1.141, 0.1.160, 0.1.171, 0.1.172

After a period of time from several minutes to several hours, the NetKVM network interface will lose connectivity with the network, as shown here:

Rebooting or disabling and enabling the interface temporarily resolves the problem, until a few minutes or hours pass where the issue recurs. Investigating the Windows event log and host's syslog, there seem to be no events that are correlated with the connectivity loss. I have tried increasing the logging level of the NetKVM driver, but haven't been able to successfully retrieve those logs. Is there a preferred way to capture the log output of the driver?

Here also are some of the details of the VM's configuration (currently using libvirt):

<domain type='kvm' id='87'>
  <os>
    <type arch='x86_64' machine='pc-i440fx-bionic'>hvm</type>
    <loader readonly='yes' type='pflash'>/firmware/OVMF_CODE.fd</loader>
    <nvram>/firmware/OVMF_VARS.fd</nvram>
  </os>
  <features>
    <acpi/>
    <apic/>
    <hyperv>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
      <synic state='on'/>
    </hyperv>
    <vmport state='off'/>
  </features>
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>Skylake-Server-IBRS</model>
    <vendor>Intel</vendor>
    <topology sockets='2' cores='5' threads='1'/>
    <feature policy='require' name='ss'/>
    <feature policy='disable' name='vmx'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='clflushopt'/>
    <feature policy='require' name='pku'/>
    <feature policy='require' name='ssbd'/>
    <feature policy='require' name='xsaves'/>
  </cpu>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
    <timer name='hypervclock' present='yes'/>
  </clock>
...
  <devices>
    <emulator>/usr/bin/kvm-spice</emulator>
    <interface type='direct'>
      <source dev='enp59s0' mode='bridge'/>
      <target dev='macvtap4'/>
      <model type='virtio'/>
      <boot order='1'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
...
  </devices>
</domain>

I'm still in the research phase, but we're currently having issues with the NetKVM drivers.

Some details: Using Bhyve for virtualization Windows Server 2019 NetKVM 141 Stable drivers obtained from here: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.141-1/ It doesn't specify 2019 or have a folder for that so we used the Windows Server 2016 drivers, but from what I've read here in other issues that were resolved those should work as they are the same. And running a file hash seems to show that they were the same as well.

The issue is that we had the network stop working 2 nights in a row. The first night we were using the latest 164 drivers, so we decided to roll back to the 141 Stable version as we had issues on Windows 2016 servers with the newer drivers. The second night the same thing, network just stopped.

When I went to the driver in Device Manager it noted this for the status. No drivers are installed for this device. yet the driver files were still there, it also showed as Disabled here in the and in the network panel. One other thing it showed is that it was in the D3 power state rather than D0, though I wasn't sure if this was just due to it being disabled or not. I didn't see any configuration for making this device not sleep so I figured it wasn't due to that, but this I'm not certain about.

Other than the errors related to a network being disabled I couldn't find any data in Event Viewer indicating why the network drivers were disabled.

I also tried TraceView tool using the PDB in the iso that we downloaded for the drivers above as per your readme. But when I tried to create a new session with that PDB it says PDB file does not contain provider information. so I am unable to run this. https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/NetKVM/Documentation/Tracing.md

Do you have any recommendations for how we can go about figuring out the issue with this driver? I'm not as familiar with getting data for driver issues, so perhaps I'm missing some key information in Event Viewer by either not looking in the right spot or I don't have an appropriate log enabled. Or perhaps there is a log file with more data that I am unaware of for device drivers.

Please let me know what information you might need to help you or me investigate this issue.

There is an incompatibility between the "Citrix Indirect Display Adapter" installed by Citrix Workspaces for Windows version 1812 (originally Citrix Receiver) and the QXL DOD adapter driver for Windows 10.

To reproduce:

• Run VM with Windows 10 build 1803
• Relevant VM config: Video QXL, Display Spice, USB Tablet device
• Install Spice Guest Tools (stable or latest)
• Install Citrix Workspaces 1812 (https://www.citrix.de/downloads/workspace-app/windows/workspace-app-for-windows-latest.html)
• Reboot VM

==> After reboot, host mouse and automatic resolution adjustment no longer work. Reinstalling Spice tools has no effect.

Solution:

Open device manager, delete "Citrix Indirect Display Adapter", reboot VM.

I have a standard Windows Server 2016 boot disk and also a block storage disk. Restarting the server, I get these events logged. seems like an issue with the drivers, and the info in that KB was not useful. Reformatting the disks and such aren't helping.

Is your feature request related to a problem? Please describe. The current NetKVM driver allocates Rx buffers based on whether the driver supports RSC, instead of whether the RSC is enabled on the VirtIO network adapter or tso is enabled on the host side. For example, for NetKVM driver with NDIS 6.3 and above, buffers with roughly total size 64K are allocated for Rx side. However, if the tso is disabled from host side(guest_tso4/6=off w/o VIRTIO_NET_F_GUEST_TSO4/6) or the RSC is disabled on the VirtIO network adapter in the Windows guest, the host sends MTU size packets to the guest. In this case, allocating the 64K size buffer is a waste.

Describe the solution you'd like ParaNdis_InitializeContext initializes the nMaxDataSizeHwRx as roughly 64K as following,

....
#if PARANDIS_SUPPORT_RSC
pContext->MaxPacketSize.nMaxDataSizeHwRx = MAX_HW_RX_PACKET_SIZE;
pContext->MaxPacketSize.nMaxFullSizeOsRx = MAX_OS_RX_PACKET_SIZE;
#else
...

In CreateRxDescriptorOnInit funcition, Rx buffers are allocated based on the size of nMaxDataSizeHwRx initialized as above,

...
    ULONG ulNumPages = m_Context->MaxPacketSize.nMaxDataSizeHwRx / PAGE_SIZE + 2;
...
while (ulNumPages > 0)
{
..
allocate buffers
...
}
...

In InitializeRSCState function, the tso and RSC value are being negotiated and then VIRTIO_NET_F_GUEST_TSO4 feature will be Acked accordingly. So I suggest to set the value of pContext->MaxPacketSize.nMaxDataSizeHwRx in InitializeRSCState after the negotiation of tso and RSC has been done, i.e. set nMaxDataSizeHwRx as MTU size if VIRTIO_NET_F_GUEST_TSO4 is not Acked. For example, if VIRTIO_NET_F_GUEST_TSO4 is not Acked, add following,

pContext->MaxPacketSize.nMaxDataSizeHwRx = pContext->MaxPacketSize.nMaxFullSizeOS + ETH_PRIORITY_HEADER_SIZE; 
pContext->MaxPacketSize.nMaxFullSizeOsRx = pContext->MaxPacketSize.nMaxFullSizeOS;

Additional context This change can help reducing the total memory especially with multiple queue or cpus.

If a poor designed TCP server application doesn't receive data from windows socket function driver afd.sys as quickly as possible, then afd.sys will hold recv buffers temporaryly, and don't call NdisReturnNetBufferLists until afd return-buffer timer expired(at most 1 second).At this time, if there are many packets send in by tcp clients, there may not be enough receive buffer descriptors in the vring to receive packets, and finally packet loss.

Notes:

1. If someone found this patch could help you to avoid packet loss, the most probably root cause is the application is not well-designed;
2. An another way which can avoid packet loss under the situation described above is set DoNotHoldNICBuffers to 1(REG_DWORD) under registry path HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\AFD\Parameters. But microsoft had never mentioned this registry (even hadn't document the behavior of HoldNICBuffers), so the registry param maybe not working in the future version of windows.
3. According to my analysis, the pusrpose of HoldNICBuffers behavior in afd.sys is mainly to decrease memory copy times when deliver incomming tcp packets to the buffer of recv/wsarecv systemcall. But sometimes it may lead packet loss.

Signed-off-by: junjiehua [email protected] Reviewed-by: yongduan [email protected]

after my proxmoxve was crash and reboot,i find the balloon was not report the mem,only one vm was report.

it is the vm when use qm monitor ==> info balloon

qm> info balloon balloon: actual=16384 max_mem=16384 last_update=1666319200

i try to uninstall and reinstall it。but it also not works

how can i fix it？

Describe the bug I'm trying to build the drivers from scratch using the current master branch and I am unable to do so. My current main goal is to build the Win10 drivers, but i will need to build for win 8 and win 8.1 in the future.

Logs are attached (2, 3) to the issue for both win8 and win10, however the first pass appears to be 2 major issues with win10 building:

• Signing fails because SignTool cant find a certificate which matches all given criteria
• VioSock can't find viosocklib.dll or viosocklib.pdb but files exist.

To Reproduce I'm running on a windows server 2019 KVM, freshly installed. No windows updates. Following the build instructions to build the drivers using ewdk 1903 and 2004 from the wiki (1) I setup the EWDK 2004 environment with the dvl files from EWDK 1903, and installed the required components (WinFsp, CPDK WIndows 10, .NET framework 4.8, VS 2013 redistribution x86)

• downloaded the .zip from the master.branch
• extracted the contents to the desktop
• ran LaunchBuildEnv.bat from the edwk2004 directory
• in the environment set VIRIO_WIN_NO_ARM=True
• change dir to the extracted contents
• .\buildAll.bat AMD64
• save `buildfre_win8_amd64.log
• edit the .\BuilAll.bat file to remove Win8 and Win8.1 such as call tool\build.bat virtio-win.sln "Win10" %*
• .\BuildAll.bat AMD64
• save buildfree_win10_amd64.log

1. https://github.com/virtio-win/kvm-guest-drivers-windows/wiki/Building-the-drivers-using-EWDK-1903-2004
2. buildfre_win8_amd64.log
3. buildfre_win10_amd64.log

Expected behavior Drivers build resulting in proper test signed (or unsigned) VirtIO drivers and .sdv files in the <driver>\install\Win<version>\amd64\ directory in a sate where they can be signed and tested for WHQL certification.

Screenshots N/A

Host:

• Disto: Ubuntu 22.04
• Kernel version: 5.15.0-50.56
• QEMU version: 1:5.2+dfsg-2ubuntu6.2
• QEMU command line: N/A (can provide if needed)
• libvirt version: 8.0.0-1ubuntu7.1
• libvirt XML file: N/A (can provide if needed)

VM:

• Windows version: Windows Server 2019 Datacenter 1809, os build 17763.107
• Which driver has a problem: None
• Driver version or commit hash that was used to build the driver: Drivers on system are from the mm220 commit, drivers being built are from the master branch.

Hi

From what I get a virtio-gpu windows guest driver already exist but there is no support for 3D acceleration with VirGL (on host) as renderer

On Linux a 3D acceleration on a virtio-gpu-gl is supported through Mesa Drivers

For windows there is support for Mesa Driver, I would like to investigate the possibility of using this drivers to interact with the virtio-gpu of this repo so to enable 3D acceleration on windows

The basic idea is:

1. Virtio-gpu-gl driver exposing a vGPU
2. Mesa driver using such vGPU
3. WindowsOS using Mesa Driver

(I know about VFIO, GPUPassthrough, Nvidia Grid ecc, but this would be a more Flexible, Hardware Agnostic and Open Source option)

Is this achievable? Or am I missing something?

Thanks, Luca

Describe the bug

Although it is possible that the flag getattr_in.getattr.getattr_flags will be set to zero in line 1107, the flag is always reset back to 0 in line 1110.

Screenshots viofs/svc/virtiofs.cpp:GetFileInfoInternal()