Windows USB integration with R4.1

  1. I rebooted the box (just to start with everything fresh).
  2. Deleted all windows qubes.
  3. Re-ran your command to create the cube on dom0: qvm-create --standalone --property virt_mode=hvm --property memory=4096 --property maxmem=0 --label blue win10
  4. Mounted the usb drive into Red as /mnt/usb/
  5. In qube manager, went to settings, increased system disk space to 60G. (It defaults to 10G, which is too small for a Windows installation.)
  6. In the advanced tab, selected “Boot qube from CDROM”. Selected Red and /mnt/usb/windows.iso. Then it boots.
    Notification says the iso is available.
    Notification says the qube is starting.
    Text window briefly pops up (less than 2 seconds, not long enough to read).
    Then nothing. It appears to hang.

Looking at the logs:

  • guest-win10.log: Shows expected startup sequence. No issues.
  • guest-win10-dm.log: Long file. there’s a part that says === Press enter for shell ===. Then it allocates the gui and socket. Then br0: port 2 entered disabled state, vif7.0-emu left promiscuous mode, and br0 port 2 entered disabled state. This then repeats with br0: port 1 (entered disabled, left promiscuous, entered disabled). Then comes:
    qemu[230]: segfault at 0 ip [hex] sp [hex] error 4 in qemu[hex] Code: [long hex bytes]

At that point, the win10 qube is left running, but it’s dead. No gui, no installation, the USB isn’t being accessed (because it’s LED isn’t blinking).

Are you sure that iso is ok?

It was when I tried it a few days ago on Qubes 4.0.x.
I’ll recheck the sha1 on it.

Update: Same sha1. I took it over to my Linux box and it booted under VirtualBox.

Did you figure out how to install qubes-windows-tools to dom0?

I think I forgot set kernel to empty
qvm-prefs [windows-qube] kernel ""

Look at this topic. In short you can easily build it from sources and help to test it.

But there is no necessary QWT to test USB integration.

I have a suspicion…

My windows.iso is over 4G.
I’m trying a different windows.iso that is under 4G. (Waiting for the usb to finish writing.) My suspicion is that the usb-to-dom0 mount may be limited to 4G.

Empty kernel didn’t help? In common you don’t need to get iso to dom0, use it from sys-usb.

  1. Correct – empty kernel didn’t help.

  2. Got Windows to start the install process! The .iso file must NOT be larger than 4G. Now for the 30 minutes of “installing Windows”…

When this finished, I’ll be able to test the USB support. (I’m very excited that I got it this far.)

1 Like

One more finding to report: If the windows iso fails and it reports a segfault with the qube still running, then you can’t kill it from the qube manager AND shutdown will hang indefinitely. (Hard-shutdown by holding in the power button.)

Woo hoo!

Got Windows installed. Added the stubdom-linux-full, and set feature stubdom-qrexec.

I just tried a bunch of USB devices that I have lying around within arms reach of me.

  • Built-in laptop webcam: Attached and seen by Windows. Windows loads the drivers automagically and it appears to work.
  • Sound. Nope – requires pulseaudio. (Not a problem, my workaround is to assign the sound PCI card to Windows.)
  • USB thumb drive. Seen and detected as a drive. But eject generates a Qubes notification error "Detaching device USB… from win10 failed.
  • Built-in laptop fingerprint reader: Attached and seen by Windows. Windows loads the drivers.
  • USB calculator (I love my toys): Appears as a USB Composite device and acts like a keyboard. Works.

This is looking REALLY GOOD.

1 Like

Good news!

To get sound works in Windows try
qvm-features [windows-qube] audio-model ich6
and reboot VM.

Are you sure you tried attach USB not block device?
Was sys-usb (fedora-34?) updated with current-testing repos?..

Re: Sound
Woo hoo! Adding qvm-features [windows-qube] audio-model ich6 works great! Sound without any special changes.

Re: USB drive
I have a usb thumb drive. It has 1 partition. The partition is vfat named “NEAL”.
If I plug it into a linux box, it automounts as “NEAL”.
If I plug it into a standalone Windows box, it is seen as “NEAL (D:)”
If I plug it into Qubes 4.1, it is seen as two USB block devices:

  • sys-usb:sda - Flash_Disk()
  • sys-usb:sda1 - Flash_Disk (NEAL)

I tried attaching each block device (1 at a time) to the win10 VM. Both attach/detach cleanly from the Qubes side. However, win10 doesn’t see either of them.

The same drive also appears under “USB Devices” as sys-usb:2-4.1.2 - USB_2.0_Flash_Disk_[hex]. Attaching this to win10 immediately sees the drive and sees “NEAL (D:)”. Detaching generates a Qubes notification that it has been detached, and then a second notification ‘Error’ that it cannot be detached. (I think the eject function is being called twice.)

What do you think of lag in the sound? Really just curious. I bought a 20 dollar usb add on board and use that for a FIIO K3 dac in windows ;so, I probably won’t change unless my wife steals my DAC… :grinning:

This used to work on one of my VM’s. It’s broken now but on my newest HVM activating stubdom-qrexec just leads to a black screen and then halts.
Can we get a qvm-features list over what we need?
Several options clash, e.g. qrexec and stubdom-qrexec.
Currently stubdom-qrexec needs to be deleted, not just set to 0.
I installed full QWT and this package and USB passthrough worked magically. Now on my new one it doesn’t.
qvm-features gui-emulated 1?
qvm-features gui 1?

With current-testing for sys-usb you mean this repo right?

# Qubes updates candidates repository
#deb [arch=amd64] tor+http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/vm buster-testing main

Host system halted or HVM??? What about log messages in /var/log/xen/console/guest-[qube-name]-dm.log ?

Known windows related qvm-features:
gui-emulated - requires 1 for windows 10 systems with QWT, force stubdomain window instead of waiting qubes gui agent
gui - advertised by QWT to 1 to drop stubdomain window and wait qubes gui agent. Requires manual set 0 for windows 10 and keep 1 for windows 7 with QWT.
slic - feature to provide license stored in ACPI SLIC table to HVM. Might be useful for Windows 7/10 OEM version installed from host systems with fabricated Windows. Might be /sys/firmware/acpi/tables/SLIC or file, copied from another host.
audio-model - emulated model QEMU audio device. Might be ich6 or ich9.
qrexec - feature advertised by QWT to be ready to qrexec communication with guest qrexec-agent.
stubdom-qrexec - feature to redirect USB communication via stubdomain instead of guest service (which is unavailable for Windows).

correct. Pretty useful to enable on beta-version testing

With stubdom-qrexec 1:
qrexec-daemon startup failed: 2021-07-17 19:15:59.160 qrexec-daemon[32764]: qrexec-daemon.c:135:sigchld_parent_handler: Connection to the VM failed
VM halts. Qubes has never halted.

With

rpc-clipboard  1
gui            0
gui-emulated   1
qrexec         1

and trying to attach USB devices:
Error: QubesException - Device attach failed: [Timestamp] qrexec-client[44971]: qrexec-client.c:671:main: Failed to open datra vchan connection

Thanks for tipping me about gui 0. With gui 1 I only could launch a few games, which were buggy. Now I can launch pretty much any game, but there seems to be input problems without USB passthrough working.

Did you install xen-hvm-stubdom-linux-full package? Does dom0 fully updated with current-testing repos?

Yes, and strange thing is USB passhtrough worked on my first Windows HVM.
But after a lot of fiddling with it, I cannot launch it. I can do some more testing later.
But on the one I’ve been using the past couple days, I get those errors. Just strange.

Also log messages from stubdomain could help - /var/log/xen/console/guest-[qube-name]-dm.log