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.

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.

Hi,

Starting with qemu-3.1 netkvm driver stops working on my setup, randomly, but very soon after boot on Windows 10. The network is not working anymore and I cannot disable the network interface or driver (waits forever to disable it).

Host OS: Linux kvm 5.2.0-arch2-1-vfio #1 SMP PREEMPT Thu Jul 11 09:54:19 EEST 2019 x86_64 GNU/Linux

The problem is present also on older kernels (I observed the problem after upgrading to qemu 3.1).

Guest OS: Windows 10 1809 LTSC (latest updates)

The problem is present also on older Windows versions (I observed the problem after upgrading to qemu 3.1).

Tried with virtio-win 0.1.160, 0.1.164, 0.1.171.

My VM config:

#!/bin/sh

VM=$(basename $0)

KVM_ROOT='/mnt/storage/kvm' STORAGE_DIR="/dev/zvol/storage/kvm/vms/${VM}" DEVS='01:00.0,01:00.1,0b:00.0,00:1a.0,0d:00.0,0d:00.1'

$KVM_ROOT/scripts/unbind_devices ${DEVS}

qemu-system-x86_64
-daemonize
-pidfile "/run/qemu-${VM}.pid"
-nodefaults -no-user-config
-name "${VM}",process="${VM}"
-accel kvm
-boot menu=on
-rtc base=localtime,clock=vm,driftfix=slew
-global kvm-pit.lost_tick_policy=discard -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1
-no-hpet
-machine pc-i440fx-3.0,accel=kvm,usb=off,vmport=off
-m 8192 -mem-path /dev/hugepages -mem-prealloc
-realtime mlock=off
-cpu host,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,kvm=off,hv-vendor-id=none,hv-crash,hv-reset,hv-vpindex,hv-runtime,hv-synic,hv-stimer
-smp sockets=1,cores=2,threads=2
-drive if=pflash,file="OVMF_CODE-pure-efi.fd",format=raw,readonly
-drive if=pflash,file="OVMF_VARS-pure-efi.fd",format=raw
-debugcon file:ovmf.log -global isa-debugcon.iobase=0x402
-vga none
-nographic
-monitor unix:/run/qemu-${VM}.monitor,server,nowait
-serial none
-parallel none
-chardev socket,id=qga0,path=/run/qemu-${VM}.agent,server,nowait
-device virtio-serial
-device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0

-device vfio-pci,host=01:00.0,bus=pci.0,addr=0x7,multifunction=on,x-no-kvm-intx=on
-device vfio-pci,host=01:00.1,bus=pci.0,addr=0x7.1,x-no-kvm-intx=on
-device vfio-pci,host=0b:00.0,bus=pci.0,x-no-kvm-intx=on
-device vfio-pci,host=00:1a.0,bus=pci.0,x-no-kvm-intx=on
-device vfio-pci,host=0d:00.0,bus=pci.0
-device vfio-pci,host=0d:00.1,bus=pci.0

-usb
-device usb-host,id='Logitech_Inc_G502_Proteus_Spectrum_Optical_Mouse',vendorid=0x046d,productid=0xc332
-device usb-host,id='Microsoft_Corp_Natural_Ergonomic_Keyboard_4000',vendorid=0x045e,productid=0x00db

-netdev tap,id=brlan,ifname=${VM},vhost=on,script=${KVM_ROOT}/scripts/vm_ifup_brlan -device virtio-net-pci,netdev=brlan,mac=52:54:00:00:00:71,ioeventfd=on

-object iothread,id=iothread1
-device virtio-scsi-pci,id=scsi0,iothread=iothread1,num_queues=4

-drive id=drive0,if=none,file="${STORAGE_DIR}/system",format=raw,cache=none,aio=native,discard=unmap,detect-zeroes=on -device scsi-hd,drive=drive0,scsi-id=0,bootindex=2
-drive id=drive1,if=none,file="${STORAGE_DIR}/data",format=raw,cache=none,aio=native,discard=unmap,detect-zeroes=on -device scsi-hd,drive=drive1,scsi-id=1

${OPTS}

Thanks.

Introduce BALLOON_INFLATE_IGNORE_LOWMEM macro to avoid the check for low memory before further inflating the balloon towards the target set by the hypervisor.

This enables the hypervisor to reclaim guest cold pages. The inflating balloon causes pressure, which Windows resolves by paging-out cold memory to the Pagefile.

Co-authored-by: Carl Waldspurger <[email protected]@nutanix.com> Co-authored-by: Florian Smidth [email protected] Co-authored-by: Sergey Bykov [email protected] Co-authored-by: Jonathan Davies [email protected]

Describe the bug When trying to install Windows 2022, using virtio-win-0.1.217.iso, I get an error:

No signed device drivers were found. Make Sure that the installation media contains the correct drivers, and then click OK.

To Reproduce

1. Create a new QEMU KVM instance, booting from en-us_windows_server_2022_updated_june_2022_x64_dvd_ac918027.iso
2. Attach the virtio-win-0.1.217.iso file, taken from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.217-2/
3. Boot the VM.
4. On the Load Driver screen, Browse to the CD drive, then Balloon, then 2k22\amd64.
5. Hit OK.

Expected behavior The Windows 2022 Installer should load the appropriate virtio drivers from the subdirectory.

Screenshots

Host:

• Disto: Proxmox
• Kernel version: 5.15.35-3-pve
• QEMU version: 6.2
• QEMU command line
• libvirt version
• libvirt XML file

VM:

• Windows version: en-us_windows_server_2022_updated_feb_2022_x64_dvd_d4a089c1.iso
• Which driver has a problem: Balloon, NetKVM, Vioscsi, Vioserial
• Driver version or commit hash that was used to build the driver: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.217-2/

Additional context Testing with 0.1.215 appears to work, and Windows is able to load drivers.

So I'm assuming this is some regression introduced between 0.1.215 and 0.1.217-2?

Describe the bug When saving a macro-enabled spreadsheet in Excel 2019, I get "The document was saved successfully, but Excel cannot re-open it because of a sharing violation". This doesn't happen on block device mounts.

Host:

• Disto: Fedora 36
• Kernel version: 5.17.11-300.fc36.x86_64
• QEMU version: 6.2.0 (qemu-6.2.0-10.fc36)
• QEMU command line : /usr/bin/qemu-system-x86_64 -name guest=win10,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-5-win10/master-key.aes"} -blockdev {"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"} -blockdev {"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/win10_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"} -machine pc-q35-6.2,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format,memory-backend=pc.ram -accel kvm -cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff -m 8092 -object {"qom-type":"memory-backend-memfd","id":"pc.ram","share":true,"x-use-canonical-path-for-ramblock-id":false,"size":8485076992} -overcommit mem-lock=off -smp 8,sockets=1,dies=1,cores=4,threads=2 -uuid 9e17debc-56f8-4202-a6f0-74e957999cbc -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=28,server=on,wait=off -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot menu=on,strict=on -device pcie-root-port,port=16,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=17,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=18,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=19,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 -device pcie-root-port,port=20,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 -device pcie-root-port,port=21,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 -device pcie-root-port,port=22,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 -device pcie-root-port,port=23,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7 -device pcie-root-port,port=24,chassis=9,id=pci.9,bus=pcie.0,multifunction=on,addr=0x3 -device pcie-root-port,port=25,chassis=10,id=pci.10,bus=pcie.0,addr=0x3.0x1 -device pcie-root-port,port=26,chassis=11,id=pci.11,bus=pcie.0,addr=0x3.0x2 -device pcie-root-port,port=27,chassis=12,id=pci.12,bus=pcie.0,addr=0x3.0x3 -device pcie-root-port,port=28,chassis=13,id=pci.13,bus=pcie.0,addr=0x3.0x4 -device pcie-root-port,port=29,chassis=14,id=pci.14,bus=pcie.0,addr=0x3.0x5 -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 -blockdev {"driver":"host_device","filename":"/dev/sdc","aio":"native","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-1-format","read-only":false,"discard":"unmap","cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-1-storage"} -device ide-hd,bus=ide.0,share-rw=on,drive=libvirt-1-format,id=sata0-0-0,bootindex=1,write-cache=on -chardev socket,id=chr-vu-fs0,path=/var/lib/libvirt/qemu/domain-5-win10/fs0-fs.sock -device vhost-user-fs-pci,id=fs0,chardev=chr-vu-fs0,tag=D,bus=pci.5,addr=0x0 -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=32 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:c1:7c:0d,bus=pci.1,addr=0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0,index=0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev socket,id=chrtpm,path=/run/libvirt/qemu/swtpm/5-win10-swtpm.sock -tpmdev emulator,id=tpm-tpm0,chardev=chrtpm -device tpm-crb,tpmdev=tpm-tpm0,id=tpm0 -device usb-tablet,id=input0,bus=usb.0,port=1 -audiodev {"id":"audio1","driver":"spice"} -spice port=0,disable-ticketing=on,image-compression=off,gl=on,rendernode=/dev/dri/renderD128,seamless-migration=on -device qxl-vga,id=video0,max_outputs=1,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,bus=pcie.0,addr=0x1 -device ich9-intel-hda,id=sound0,bus=pcie.0,addr=0x1b -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0,audiodev=audio1 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on
• libvirt version: 8.1.0
• libvirt XML file:

<domain type="kvm">
<name>win10</name>
<uuid>9e17debc-56f8-4202-a6f0-74e957999cbc</uuid>
<metadata>
  <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
    <libosinfo:os id="http://microsoft.com/win/10"/>
  </libosinfo:libosinfo>
</metadata>
<memory unit="KiB">8286208</memory>
<currentMemory unit="KiB">2097152</currentMemory>
<memoryBacking>
  <source type="memfd"/>
  <access mode="shared"/>
</memoryBacking>
<vcpu placement="static">8</vcpu>
<os>
  <type arch="x86_64" machine="pc-q35-6.2">hvm</type>
  <loader readonly="yes" type="pflash">/usr/share/edk2/ovmf/OVMF_CODE.fd</loader>
  <nvram template="/usr/share/edk2/ovmf/OVMF_VARS.fd">/var/lib/libvirt/qemu/nvram/win10_VARS.fd</nvram>
  <boot dev="hd"/>
  <bootmenu enable="yes"/>
</os>
<features>
  <acpi/>
  <apic/>
  <hyperv mode="custom">
    <relaxed state="on"/>
    <vapic state="on"/>
    <spinlocks state="on" retries="8191"/>
  </hyperv>
  <vmport state="off"/>
</features>
<cpu mode="host-passthrough" check="none" migratable="on">
  <topology sockets="1" dies="1" cores="4" threads="2"/>
</cpu>
<clock offset="localtime">
  <timer name="rtc" tickpolicy="catchup"/>
  <timer name="pit" tickpolicy="delay"/>
  <timer name="hpet" present="yes"/>
  <timer name="hypervclock" present="yes"/>
</clock>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<pm>
  <suspend-to-mem enabled="no"/>
  <suspend-to-disk enabled="no"/>
</pm>
<devices>
  <emulator>/usr/bin/qemu-system-x86_64</emulator>
  <disk type="block" device="disk">
    <driver name="qemu" type="raw" cache="none" io="native" discard="unmap"/>
    <source dev="/dev/sdc"/>
    <target dev="sda" bus="sata"/>
    <shareable/>
    <address type="drive" controller="0" bus="0" target="0" unit="0"/>
  </disk>
  <controller type="usb" index="0" model="qemu-xhci" ports="15">
    <address type="pci" domain="0x0000" bus="0x02" slot="0x00" function="0x0"/>
  </controller>
  <controller type="pci" index="0" model="pcie-root"/>
  <controller type="pci" index="1" model="pcie-root-port">
    <model name="pcie-root-port"/>
    <target chassis="1" port="0x10"/>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0" multifunction="on"/>
  </controller>
  <controller type="pci" index="2" model="pcie-root-port">
    <model name="pcie-root-port"/>
    <target chassis="2" port="0x11"/>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x1"/>
  </controller>
  <controller type="pci" index="3" model="pcie-root-port">
    <model name="pcie-root-port"/>
    <target chassis="3" port="0x12"/>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x2"/>
  </controller>
  <controller type="pci" index="4" model="pcie-root-port">
    <model name="pcie-root-port"/>
    <target chassis="4" port="0x13"/>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x3"/>
  </controller>
  <controller type="pci" index="5" model="pcie-root-port">
    <model name="pcie-root-port"/>
    <target chassis="5" port="0x14"/>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x4"/>
  </controller>
  <controller type="pci" index="6" model="pcie-root-port">
    <model name="pcie-root-port"/>
    <target chassis="6" port="0x15"/>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x5"/>
  </controller>
  <controller type="pci" index="7" model="pcie-root-port">
    <model name="pcie-root-port"/>
    <target chassis="7" port="0x16"/>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x6"/>
  </controller>
  <controller type="pci" index="8" model="pcie-root-port">
    <model name="pcie-root-port"/>
    <target chassis="8" port="0x17"/>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x7"/>
  </controller>
  <controller type="pci" index="9" model="pcie-root-port">
    <model name="pcie-root-port"/>
    <target chassis="9" port="0x18"/>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0" multifunction="on"/>
  </controller>
  <controller type="pci" index="10" model="pcie-root-port">
    <model name="pcie-root-port"/>
    <target chassis="10" port="0x19"/>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x1"/>
  </controller>
  <controller type="pci" index="11" model="pcie-root-port">
    <model name="pcie-root-port"/>
    <target chassis="11" port="0x1a"/>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x2"/>
  </controller>
  <controller type="pci" index="12" model="pcie-root-port">
    <model name="pcie-root-port"/>
    <target chassis="12" port="0x1b"/>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x3"/>
  </controller>
  <controller type="pci" index="13" model="pcie-root-port">
    <model name="pcie-root-port"/>
    <target chassis="13" port="0x1c"/>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x4"/>
  </controller>
  <controller type="pci" index="14" model="pcie-root-port">
    <model name="pcie-root-port"/>
    <target chassis="14" port="0x1d"/>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x5"/>
  </controller>
  <controller type="sata" index="0">
    <address type="pci" domain="0x0000" bus="0x00" slot="0x1f" function="0x2"/>
  </controller>
  <controller type="virtio-serial" index="0">
    <address type="pci" domain="0x0000" bus="0x03" slot="0x00" function="0x0"/>
  </controller>
  <filesystem type="mount" accessmode="passthrough">
    <driver type="virtiofs"/>
    <source dir="/mnt/d"/>
    <target dir="D"/>
    <address type="pci" domain="0x0000" bus="0x05" slot="0x00" function="0x0"/>
  </filesystem>
  <interface type="network">
    <mac address="52:54:00:c1:7c:0d"/>
    <source network="default"/>
    <model type="virtio"/>
    <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
  </interface>
  <serial type="pty">
    <target type="isa-serial" port="0">
      <model name="isa-serial"/>
    </target>
  </serial>
  <console type="pty">
    <target type="serial" port="0"/>
  </console>
  <channel type="spicevmc">
    <target type="virtio" name="com.redhat.spice.0"/>
    <address type="virtio-serial" controller="0" bus="0" port="1"/>
  </channel>
  <input type="tablet" bus="usb">
    <address type="usb" bus="0" port="1"/>
  </input>
  <input type="mouse" bus="ps2"/>
  <input type="keyboard" bus="ps2"/>
  <tpm model="tpm-crb">
    <backend type="emulator" version="2.0"/>
  </tpm>
  <graphics type="spice">
    <listen type="none"/>
    <image compression="off"/>
    <gl enable="yes"/>
  </graphics>
  <sound model="ich9">
    <address type="pci" domain="0x0000" bus="0x00" slot="0x1b" function="0x0"/>
  </sound>
  <audio id="1" type="spice"/>
  <video>
    <model type="qxl" ram="65536" vram="65536" vgamem="16384" heads="1" primary="yes"/>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
  </video>
  <redirdev bus="usb" type="spicevmc">
    <address type="usb" bus="0" port="2"/>
  </redirdev>
  <redirdev bus="usb" type="spicevmc">
    <address type="usb" bus="0" port="3"/>
  </redirdev>
  <memballoon model="virtio">
    <address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/>
  </memballoon>
</devices>
</domain>

VM:

• Windows 11
• VirtioFsSvc
• 0.1.215

As we know, QEMU supports PCI pvpanic. Also, Linux has implemented its pvpanic PCI driver. However, the pvpanic PCI driver has been missing on Windows side.

This patch implements supporting pvpanic PCI driver for Windows. Both ISA and PCI pvpanic drivers share the same set of driver source code, as well as same driver binary(.sys). But they have separate INF file since the ID of ISA and PCI device are different.

QEMU options for pvpanic PCI device -device pvpanic-pci

Since the pvpanic driver is being deployed for just sending the panic event to notify the crash of the guest. It is not necessary to support multiple pvpanic devices in one guest. Since ISA and PCI device share the same driver, one of the driver will fail to be loaded if both ISA and PCI device exist in the same guest. However, this doesn't affect the crash event notification since the loaded driver always works as expected.

In case of supporting the co-existence of ISA and PCI pvpanic devices, two implementations are available.

1. Split the code and build out separate driver binaries
2. Share the same code but split the variables and callback functions for ISA and PCI driver However, these implementations are more complicated. These may be implemented in future if required.

Signed-off-by: Annie Li [email protected] Reviewed-by: Darren Kenny [email protected]

It looks like current version of ivshmem binary is very old here: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/upstream-virtio/

It would be cool to have fresh binaries available

Issue description In v0.1.215-1, v0.1.215-2, v0.1.217-1, and v0.1.217-2 Backblaze client causes the Virtio-FS Service to crash on files > 4190000 bytes (-ish). With v0.1.204, the service survives, but the Backblaze client reported an error of 'TEMPORARY_OTHER' for the file and cannot be backed up.

To Reproduce Attempting to use the Backblaze personal backup client to back up the attached G0011522.JPG from a virtio-fs directory will reliably trigger the failure. The Virtio-FS service crashes, and the Z: drive disappears. The backblaze client treats the situation as if Z: was a USB drive that disconnected, and carries on ignoring the rest of the Z: drive.

Using explorer to copy the file into the VM succeeds. Using Backblaze to back up the file from the copy inside the VM also succeeds.

Expected behavior The service should remain up and going, and the backup client should be able to read the file and back it up. What appears to happen instead is the client successfully reads the file in 1MB chunks (presumably to scan for blocks that need to be backed up), then it comes around for a second pass and load the entire file all at once -- but instead of reading 4190259 bytes, the number of bytes returned on the read is 0, which appears to trigger a fault.

Screenshots The attached files: G0011522.JPG is the file that will cause the failure dir.txt is a listing of the directory of the virtio filesystem. BB backs files up from smallest to largest -- G0011525.JPG succeeds, at 4181721 bytes. G0011522.JPG fails at 4190259 bytes. VFS.log is the logging from virtiofs (DebugFlag set to 0xFFFFFFFF) Dante.xml.txt is the qemu configuration file.

Host:

• Distro: Ubuntu 22.04
• Kernel version: 5.15.0-33-generic
• QEMU version: 6.2.0 (6.2+dfsg-2ubuntu6)
• QEMU command line -- standard as launched from virt-manager -- see bottom
• libvirt version: 8.0 (8.0.0-1ubuntu7)
• libvirt XML file: attached -- Dante.xml.txt

VM:

• Windows version: 10 - 21H2
• Which driver has a problem: Virtio-FS
• Driver version or commit hash that was used to build the driver: 1.215-1, 1.215-2, 1.217-1, 1.217-2 (1-204 does not crash but also does not work correctly -- see above)

Additional context

Dante.xml.txt dir.txt VFS.log

/usr/bin/qemu-system-x86_64 -name guest=Dante,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-6-Dante/master-key.aes"} -blockdev {"driver":"file","filename":"/usr/share/OVMF/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"} -blockdev {"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/Dante_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"} -machine pc-q35-4.2,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format,memory-backend=pc.ram -accel kvm -cpu Cooperlake,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,sha-ni=on,umip=on,waitpkg=on,gfni=on,vaes=on,vpclmulqdq=on,rdpid=on,movdiri=on,movdir64b=on,fsrm=on,md-clear=on,avx-vnni=on,xsaves=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,hle=off,rtm=off,avx512f=off,avx512dq=off,avx512cd=off,avx512bw=off,avx512vl=off,avx512vnni=off,avx512-bf16=off,taa-no=off,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff -m 8192 -object {"qom-type":"memory-backend-file","id":"pc.ram","mem-path":"/var/lib/libvirt/qemu/ram/libvirt/qemu/6-Dante/pc.ram","share":true,"x-use-canonical-path-for-ramblock-id":false,"size":8589934592} -overcommit mem-lock=off -smp 4,sockets=1,dies=1,cores=4,threads=1 -uuid 095d4640-0dec-45bc-bfca-a527554ad2ff -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=34,server=on,wait=off -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot menu=off,strict=on -device pcie-root-port,port=16,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=17,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=18,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=19,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 -device pcie-root-port,port=20,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 -device pcie-root-port,port=21,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 -device pcie-root-port,port=22,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 -blockdev {"driver":"host_device","filename":"/dev/ezekiel-00/dante","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-3-format","read-only":false,"driver":"raw","file":"libvirt-3-storage"} -device virtio-blk-pci,bus=pci.6,addr=0x0,drive=libvirt-3-format,id=virtio-disk0,bootindex=2 -blockdev {"driver":"file","filename":"/mnt/iso/template/iso/Windows21H2.iso","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":true,"driver":"raw","file":"libvirt-2-storage"} -device ide-cd,bus=ide.0,drive=libvirt-2-format,id=sata0-0-0,bootindex=1 -blockdev {"driver":"file","filename":"/mnt/iso/template/iso/virtio-win-0.1.217-2.iso","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-1-format","read-only":true,"driver":"raw","file":"libvirt-1-storage"} -device ide-cd,bus=ide.1,drive=libvirt-1-format,id=sata0-0-1,bootindex=3 -chardev socket,id=chr-vu-fs0,path=/var/lib/libvirt/qemu/domain-6-Dante/fs0-fs.sock -device vhost-user-fs-pci,ats=on,id=fs0,chardev=chr-vu-fs0,queue-size=1024,tag=Backups,bus=pci.5,addr=0x0 -netdev tap,fd=35,id=hostnet0,vhost=on,vhostfd=37 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a2:e5:95,bus=pci.1,addr=0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -audiodev {"id":"audio1","driver":"spice"} -spice port=5901,addr=127.0.0.1,disable-ticketing=on,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device ich9-intel-hda,id=sound0,bus=pcie.0,addr=0x1b -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0,audiodev=audio1 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on