Page 1 of 1

Multiseat in Qemu

Posted: Wed 12 Nov 2014, 13:08
by Gobbi
I managed to get a multiseat (2) solution with qemu using 2 monitors and 2 input ( kb + mouse) sets.
One can use the parameters with Qemu Control Centre provided by mikeb or qemu-vm-manager provided by jamesbond in Fatdog or use directly the terminal .
I used this code from the console:

qemu-system-x86_64 -enable-kvm -vga vmware -m 2048 -smp cores=2 -usbdevice host:046d:c52b -soundhw ac97 -cdrom *.iso

Using kvm helps a lot (speed up) .

I'm using vmware video because installing vmware driver on the guest OS gives the best result for playing videos . Here , qemu is still slower than Virtual Box , so I want to look for a way to pass through the host video card to adress this issue too .

For keyboard and mouse I pass through the host usb device identified by vendor_id:product_id :
-usbdevice host:vendor_id:product_id
Vendor_id and product_id I got typing lsusb in the terminal.

About sound : for the guest , one can choose the emulated sound card that works
better , in my case -soundhw ac97 is just fine . I noticed that if qemu starts when the host system is using one specific sound card , that card is assigned to qemu .
Then I switch to the second card ( the one provided by my AMD card through HDMI - in my case ) and both host and guest have separate audio.

Posted: Wed 12 Nov 2014, 16:56
by Ted Dog
cool I have a laptop with both HDMI and VGA as well as laptop screen. just need more mice and keyboards.

Posted: Wed 12 Nov 2014, 17:07
by stemsee
Outstanding!

Posted: Wed 12 Nov 2014, 19:12
by mikeb
Neat..I think this has been asked for in the past and now you seem to have a method.

I am overdue to update me gui so not sure what to put in there without getting too hairy but I will examine this....

Mike

Posted: Thu 13 Nov 2014, 06:49
by neerajkolte
Thanks Gobbi, I will try this as soon as I get home.

- Neeraj.

Posted: Fri 14 Nov 2014, 14:09
by neerajkolte
Hi Gobbi,
I tried to use your suggestion. Following is the output of lsusb

Code: Select all

# lsusb 
Bus 001 Device 002: ID 8087:0024  
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0826:98d2 Data Transit 
Bus 002 Device 002: ID 8087:0024  
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 003: ID 058f:6387 Alcor Micro Corp. Transcend JetFlash Flash Drive
#
The entry saying "Data Transit" is my "PS2toUSB Adapter" which has both my extra kbd and mouse are connected.
My original kbd and mouse are connected to their respective ps2 ports on my motherboard.
When I add

Code: Select all

-usbdevice host:0826:98d2
to my qemu command I get error

Code: Select all

qemu: could not add USB device 'host:0826:98d2'
And my guest doesn't start.
Do you have any suggestions.
Thanks.

- Neeraj

Posted: Fri 14 Nov 2014, 16:43
by Gobbi
neerajkolte wrote:

Code: Select all

# lsusb 

Bus 001 Device 003: ID 0826:98d2 Data Transit 

The entry saying "Data Transit" is my "PS2toUSB Adapter" which has both my extra kbd and mouse are connected.
Hi neerajkolte !

I took the informations from http://qemu.weilnetz.de/qemu-doc.html#h ... 05fdevices . Take a look at 3.10 USB Emulation - 3.10.1 and 3.10.2 .
From what I understand there , there might be a conflict between USB mouse/kbd emulations and PS2 devices . Also hubs do not work .
Also have a look here : http://www.clickykeyboards.com/index.cf ... /id/124184 .
I don't know if your adapter is a direct wired one or it also has a converter chip to actually be seen as a usb device ... if it's not - it may explain what happens .

Posted: Thu 28 May 2015, 19:12
by stemsee
Have you made further progress?

Posted: Mon 01 Jun 2015, 16:31
by Gobbi
Hi @stemsee

For VGA Passthrough I chose the path of using QEMU >= 2.0 and vfio-pci & pci-stub
built inside the kernel or modules . The kernel should be >= 3.18
Carolina Vanguard R2 had the drivers thanks to @battleshooter but ,
QEMU 2.0 found from @mikeb did not work in my case .
There was also Fatdog 700 whiich has QEMU >=2.0 and vfio-pci thank to
@kirk and @jamesbond but has no pci-stub .

In the last few days - trying to do something else - I found the way to rebuild the kernel from the own puppy kernel-source sfs - I know this makes a lot a people smile :oops: .
So today I took FD700 , rebuit the kernel with pci-stub inside the kernel . After make menuconfig I chose CONFIG_PCI_STUB=y .
Who needs vfio-pci should also use CONFIG_VFIO_PCI_VGA=y or CONFIG_VFIO_PCI_VGA=M . Fatdog700 uses the last option - as a module .
AMD-VI/VT-D enabled in BIOS and working is needed . I don't use UEFI .
Inside my desktop-pc I have an AMD Radeon HD 7870XT as my main card and I took a small Nvidia GeForce GT 720 on purpose for this experiment .
I noticed the VGA infos using lspci from the terminal :
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti LE [Radeon HD 7870 XT]
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT HDMI Audio [Radeon HD 7970 Series]
and
06:00.0 VGA compatible controller: NVIDIA Corporation Device 1288 (rev a1)
06:00.1 Audio device: NVIDIA Corporation Device 0e0f (rev a1)
For the card I wanted to passthrough to QEMU's guest virtual machine I also noted the codes I needed for pci-stub using lspci -n in the terminal :
06:00.0 0300: 10de:1288 (rev a1) <-- Nvidia video
06:00.1 0403: 10de:0e0f (rev a1) <-- Nvidia audio
I added this kernel parameter to the bootloader: pci-stub.ids=10de:1288,10de:0e0f
I did not have to use mkinitcpio because pci-stub was built in the kernel .
If your board doesn't enable interrupt remapping, you need to add this to your bootloader:
vfio_iommu_type1.allow_unsafe_interrupts=1
So I rebooted the system , checked from terminal with dmesg | grep pci-stub :
[ 1.732149] pci-stub: add 10DE:1288 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[ 1.732155] pci-stub 0000:06:00.0: claimed by stub
[ 1.732157] pci-stub: add 10DE:0E0F sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[ 1.732163] pci-stub 0000:06:00.1: claimed by stub

It is also advised to blacklist radeon and nouveau but I did it anyway to be able to install Catalyst .
Now to bind the device to vfio-pci I created this script :
#!/bin/bash
modprobe vfio-pci

for dev in "$@"; do
vendor=$(cat /sys/bus/pci/devices/$dev/vendor)
device=$(cat /sys/bus/pci/devices/$dev/device)
if [ -e /sys/bus/pci/devices/$dev/driver ]; then
echo $dev > /sys/bus/pci/devices/$dev/driver/unbind
fi
echo $vendor $device > /sys/bus/pci/drivers/vfio-pci/new_id
done


I saved it as /usr/bin/vfio-bind . From the terminal I used the script to bind the Nvidia GPU : Bind the GPU:
vfio-bind 0000:06:00.0 0000:06:00.1
Now a file should be created as /etc/vfio-pci.cfg . As a matter of fact , in my case it didn't . So I did it manually with the following content :
DEVICES="0000:06:00.0 000:06:00.1"

Then I started QEMU from the terminal but I could also use Qemu Virtual Manager passing the parameters accordingly .
I used : qemu-system-x86_64 -enable-kvm -vga none -device vfio-pci,host=06:00.0,x-vga=on -device vfio-pci,host=06:00.1 -m 4096 -smp cores=4 -usbdevice host:046d:c517 -soundhw ac97 -cdrom *.iso
SUCCESS :!: :D
-vga none is to disable cirrus emulated vga.
*.iso is the name of your guest operating system .
The Nvidia card was attached through HDMI to an LGTV , and the sound I managed to hear not through HDMI but on external speakers .
Of course , one can use as much memory and number of CPU cores he (or she ) wants , bind other devices and create a virtual hard drive and boot any other OS ...
This was my particular case , I did not tried Windows or an Intel GPU .
I appologize for the length of this post :!: :oops:

I used infos from : https://bbs.archlinux.org/viewtopic.php?id=162768

Posted: Mon 01 Jun 2015, 20:34
by gcmartin
Hi @Gobbi

Very interesting for a Multi-display system where one display is the host system, while the other display is the distro running in the guest.

But, with your start up, should the sound have exited via the HDMI path to TV's speakers for the guest? Is there a manner to start so that the guest can find that audio path? This has good application for a multi-monitor system where a HDMI capable display can provide audio and video service to a guest when invoked.

Good explanation.

Posted: Mon 01 Jun 2015, 21:10
by stemsee
I don't think your post could have been much shorter without losing vital info.

Have you seen this more recent post?

http://www.linux-kvm.org/page/How_to_as ... T-d_in_KVM

So now that you have clarified the steps , I want to test the out and see how far I can get to automate them.

Posted: Tue 02 Jun 2015, 18:42
by Gobbi
My experiment was based on the infos from link I gave . That thread started long ago and there are now over 200 pages of comments . Things evolved a lot , people are using UEFI , Intel Graphics as host , Windows 10 as guest , are passing through CPU cores and reading a bit the last pages of that blog I saw how obsolete my try was .
It worked ( no HDMI sound though - but I know that to use HDMI sound even on my pc I have to install the proprietary driver - @gcmartin - I will try it ...) , but they found more direct ways to do it .
Kernels >=4.1 and QEMU >=2.3 have a lot of things that help to do it easier .
Also KVM VT-d should allow to assign devices and hot plug them in more direct way .
@stemsee
I found interesting also this : http://vfio.blogspot.com There are some smart scripts that could help to automate , but it is a bit different , newer process ...
I'll try to see if I can advance with the newer ways ...

Posted: Tue 02 Jun 2015, 19:23
by gcmartin
Does the Puppy exclusive QEMU Launcher by @MikeB offer a base to springboard from? Can a collaboration there also achieve/incorporate the results?

Posted: Tue 02 Jun 2015, 20:22
by mikeb
Actually i feel like the ball boy at Wimbledon... but interesting thread to watch at this point.
Does seem like a candidate for a specialist script rather than my little general purpose effort.

mike

Posted: Tue 02 Jun 2015, 20:57
by Gobbi
It could be this way :
1. Querry the system about the data of extra GPU that could be used in QEMU and show that data (on screen or on a file ) . This could be done automatically by some script outside (script or package) or inside a QEMU Manager - @mikeb's one or @jamesbond's one . The same automatic script could create and install the necessary scripts/files needed later before starting QEMU .
2.Put parameters in the bootloader's kernel line to avoid that/those extra GPU/GPUs beeing grabbed by the system module. - I don't see how this could be done automaticaly because we like no automatic updates . Then think about those booting from optical media , or chainloading bootloaders and it would NOT be easy .
3.Starting QEMU from a Manager could include parameters as choices in the interface - but again there are different hardware solutions and adding manually some parameters , accordingly to each own hardware , seems the natural choice : many architectures and many puppies .

It depends a lot of the owners of the QEMU Managers , because they have done already a great part of the job and they know better their packages. And a much up to date ( passthrough ) process should be chosen .

Posted: Wed 03 Jun 2015, 06:55
by stemsee
...because we like no automatic updates.
The choice would be among differing 'profiles' (logical possibilities from scan results)

Posted: Wed 19 Aug 2015, 21:48
by stemsee
Here is kernel 4.1.3-64bit with vfio vfio_pci vga iommu

https://mega.nz/#!cEwHxYrT!XjIZDldY1uib ... BRAuRnjCt0