Puppy Linux Discussion Forum

[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.

[Ted Dog]

cool I have a laptop with both HDMI and VGA as well as laptop screen. just need more mice and keyboards.

[stemsee]

Outstanding!

[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

[neerajkolte]

Thanks Gobbi, I will try this as soon as I get home.

- Neeraj.

[neerajkolte]

Hi Gobbi,
I tried to use your suggestion. Following is the output of lsusb

[Gobbi]

[stemsee]

Have you made further progress?

[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 .
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
-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

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

[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.

[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_assign_devices_with_VT-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.

[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 ...

[gcmartin]

Does the Puppy exclusive QEMU Launcher by @MikeB offer a base to springboard from? Can a collaboration there also achieve/incorporate the results?

[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

[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 .