Requesting for aid loading display service, and loading GPU driver to VFIO.

[No-Biggie805]

Hi, i have a Clevo Notebook and installed clean fedora running alongside KDE neon and Windows 10, no additional configuration here apart from the ones used from the mbpt.sh script, but still i am facing a few problems, first is about looking glass and then when trying to bind GPU to VFIO and thus i'd need some help understanding so maybe its me too that is missing something in here.

When running ./mbpt.sh check:
mbpt_check.txt
All seems good so far.

To configure everything like normal i proceeded with mbpt.sh, once everything was done i continued on to connecting to RDP and the starting the looking client which gave me an error:
looking_glass_error.txt

Now for the trivial VFIO problem i even have this same issue on KDE neon honestly.
When running ./mbpt.sh start it goes well and display-Spice comes up, should i use instead of looking glass, if yes what TLP port do i use?
Meanwhile VFIO fails to bind the GPU giving me issue: vfio 0000:01:00.0: failed to open /dev/vfio/1: No such file or directory, then it tries to unbind and idles at there.

Output after running mbpt.sh start:
mbpt_start.txt

To maybe help a little i w'd like to show my IOMMU group and which driver my GPU is currently bound:
IOMMU_grouping.txt
GPU_driver_bind.txt

My laptop is a Clevo P65_67SE
Running fedora 34;
CPU:Intel I7-4820HQ;
dGPU: Nvidia GTX 970M;
iGPU:intel hd 4600;
Ram:16Gb DDR3;

Any help is much appreciated :).
Thank you for everything so far.

[T-vK]

Looking at your start log, the first thing that needs be addresses is

modprobe: ERROR: could not insert 'kvmgt': No such device
modprobe: FATAL: Module vfio-mdev not found in directory /lib/modules/5.16.17-100.fc34.x86_64

I'm not sure what's causing that.

You could try disabling iGPU passthrough for now in your config.

[No-Biggie805]

Hi, thank you for responding, i commented on vm.sh file, with "#" the respecting iGPU lines and functions, please notify if anything's missing.
I leave in a .txt what i have:vm.txt

The output after a reset turns out to be the same except with the part of the iGPU:
mbpt_start.txt
After that it idles once again..

Also in order for the script to work properly better choice is to restart the system, but then when i try to do it even when stopping(ctrl+z) and then kill it (kill -SIGKILL "PID"), won't do any justice, it just fails, would you know of away to circumvent the problem please?

[T-vK]

What I meant was set SHARE_IGPU to false in the user.conf file. There shouldn't be a need to modify the vm.sh file.
Regarding not being able to kill the process when it's stuck, I've experienced that as well sometimes. It seems to be a bug in Linux or the driver. So far I couldn't find a way to kill it without rebooting.

[No-Biggie805]

What I meant was set SHARE_IGPU to false in the user.conf file. There shouldn't be a need to modify the vm.sh file.

Also that did work, i think really the problem is on my pc, its a 4rth gen and gvt-g isn't still supported so perhaps it might be cause of dat, oh well anyways, really i think even if i passthrough the dGPU i still might have its performance just without the accelerated iGPU on the OS perhaps, so do you know of a way for me to sucessfully bind the gpu, on qemu? i searched a little and even found a forum were it was on /etc/libvirt/qemu.conf but no success thus far.. Really don 't get it, do you know if i could try attaching some start and teardown script to vm.sh or something of some way?

Regarding not being able to kill the process when it's stuck, I've experienced that as well sometimes. It seems to be a bug in Linux or the driver. So far I couldn't find a way to kill it without rebooting.

Guess i do it the painfull way then..

Thank you so far.

[T-vK]

It would be interesting to see the output of mbpt start with SHARE_IGPU set to false.
Modifying /etc/libvirt/qemu.conf shouldn't be necessary.
Looking at the log from your first post, the next problem might be that the script failed to find the IOMMU group in this line:

MobilePassThrough/scripts/main/vm.sh

Line 779 in 1527df2

echo "> IOMMU group for passthrough is ${IOMMU_GROUP}"

I like the idea of a hook/plugin mechanism in the vm.sh to add custom functionality, especially for start/teardown purposes. But at the moment that's not supported.

Edit:
The line I referenced above is not an issue. I need to delete line 778 at some point because line 783 is already doing it correctly and line 779 can then be moved below that.

Edit 2:
So according to the log of your initial post, the next issue is with binding the dGPU to the vfio driver.
Can you verify that by running the following?

sudo modprobe vfio
sudo modprobe vfio_pci
sudo modprobe vfio_iommu_type1
sudo driverctl --nosave set-override "0000:01:00.0" vfio-pci

And then check which driver that GPU is using by running:

driverctl list-devices | grep 01:00.0

Or alternatively check sudo lspci -vvvv.

[No-Biggie805]

It would be interesting to see the output of mbpt start with SHARE_IGPU set to false.
Sorry i should actually copy to a .txt file there when it was the time, but one thing i can say for sure is the output was pretty much the same ending up on the usual unbind gpu part, best i can do really now is showing the default.conf.

• default.txt

Looking at the log from your first post, the next problem might be that the script failed to find the IOMMU group in this line:

Would that affect the process or no? Just curious since you said it wasn't really an issue.

Edit 2:
So according to the log of your initial post, the next issue is with binding the dGPU to the vfio driver.
Can you verify that by running the following?
sudo modprobe vfio
sudo modprobe vfio_pci
sudo modprobe vfio_iommu_type1
sudo driverctl --nosave set-override "0000:01:00.0" vfio-pci
And then check which driver that GPU is using by running:
driverctl list-devices | grep 01:00.0
Or alternatively check sudo lspci -vvvv.

I will be honest i did this first on the command line and well i might have made kind of a mess, though i will be explaining on the process while i am showing you what i mean.
First i did was execute the commands
sudo modprobe vfio
sudo modprobe vfio_pci
sudo modprobe vfio_iommu_type1
sudo driverctl --nosave set-override "0000:01:00.0" vfio-pci //this part only works once after force reboot, if i do it again it won't override
i will leave you the log files before and after with "sudo lspci -vvvv" as driverctl list-devices | grep 01:00.0 wouldn't work after trying to bind to vfio:
executing before: default_noveau_driver.txt //sucessfully bound to noveau
after: vfio_driver.txt //weirdly now driver module is gone..

After another force reboot i went to start again "./mbpt.sh start" and shows me this:
It also shows me a new error in the beginning though i believe that now is from the network as since at the part the script did not even try to bind any gpu to vfio.
mbpt.sh_start_log.txt

I accidentally closed the issue, could you open it again please? Thank you and an apology for any confusion made..

[T-vK]

Would that affect the process or no? Just curious since you said it wasn't really an issue.

No, it's fine, just ignore it.

sudo driverctl --nosave set-override "0000:01:00.0" vfio-pci_ //this part only works once after force reboot, if i do it again it won't override i will leave you the log files before and after with "sudo lspci -vvvv" as driverctl list-devices | grep 01:00.0 wouldn't work after trying to bind to vfio: executing before: default_noveau_driver.txt //sucessfully bound to noveau after: vfio_driver.txt //weirdly now driver module is gone..

That's weird indeed. Maybe we should take a look at your dmesg and check if something obvious is going wrong.

After another force reboot i went to start again "./mbpt.sh start" and shows me this: It also shows me a new error in the beginning though i believe that now is from the network as since at the part the script did not even try to bind any gpu to vfio. mbpt.sh_start_log.txt

That network error must be coming from here:

MobilePassThrough/scripts/main/vm.sh

Lines 137 to 139 in 1527df2

	if ! sudo virsh net-list | grep default | grep --quiet active; then
	sudo virsh net-start default
	fi

Can you share the output of sudo virsh net-list and maybe also sudo virsh net-start default?

[No-Biggie805]

That's weird indeed. Maybe we should take a look at your dmesg and check if something obvious is going wrong.

Don't know what is exactly, but i had a certain guess so here's what i have, i only ran the modprobe commands you sent to me inside the terminal, executed dmesg both before and after modprobe commands:
Before: dmesg "nvidia" and its "pci adress".txt //Here i am only bound to noveau and if i dmesg vfio it doesn't show anything.

After: dmesg after trying to bind to vfio.txt //Now here vfio does show something yet seems bound to noveau, is this because i am only running through the terminal without echo??(example: echo <vendor_code> <device_code> > /sys/bus/pci/drivers/vfio-pci/new_id)?
Question, if by any means this would bind to vfio before loading the VM what would happen to my screen?? would it go blank or would my gpu just be useless on host system, just wanna know to understand what could've happen.

Can you share the output of sudo virsh net-list and maybe also sudo virsh net-start default?

Sure here:
virsh net-list errors.txt

it seems to show same thing as when loading the VM so you got that right, weird is that this did not happen before, maybe system is broke or did it pop up out of the blue or was it bypassing the problem? really dk..

[T-vK]

I'm not sure what the implications of those libvirtd segfault errors in your dmesg are, but I would think that they aren't related to the binding issue. Regarding the dracut error, I'm not sure of the implications either, but maybe updating the kernel or just booting with an older kernel version could get rid of it.

Regarding the network errors: Did you mess with any of the conf files in /etc/libvirt/ recently by any chance? It just seems odd to me that you would get those errors out of nowhere after a reboot.

(example: echo <vendor_code> <device_code> > /sys/bus/pci/drivers/vfio-pci/new_id)?

The only caveat would be that you have to run it from a privileged terminal, but can't use sudo because sudo echo and >-redirecting will give you permission errors. Other than that I guess it should work, although I'm not sure if you might have to use /sys/bus/pci/drivers/vfio-pci/bind first.
You could try using ./scripts/utils/common/tools/driver-util --help which does both.
Or you can manually do it:

MobilePassThrough/scripts/utils/common/tools/driver-util

Line 36 in 1527df2

if ! sudo bash -c "echo '0000:${PCI_ADDRESS}' > '/sys/bus/pci/drivers/${DRIVER}/bind'" &> /dev/null ; then

MobilePassThrough/scripts/utils/common/tools/driver-util

Line 40 in 1527df2

sudo bash -c "echo '${VENDOR_ID} ${DEVICE_ID}' > '/sys/bus/pci/drivers/${DRIVER}/new_id'"

[No-Biggie805]

I'm not sure what the implications of those libvirtd segfault errors in your dmesg are, but I would think that they aren't related to the binding issue. Regarding the dracut error, I'm not sure of the implications either, but maybe updating the kernel or just booting with an older kernel version could get rid of it.

I too don't have any idea too now xp, but i just updated the kernel btw, dratcut still seems to fail starting somehow, i did this only with the gpu bound to noveau since now i am starting to think about doing something else here were explain below (*), however libvirt after repairing qemu.conf mentioned down below seems to have fixed libvirt smh.
output: dmesg "nvidia" and its "pci adress".txt

Regarding the network errors: Did you mess with any of the conf files in /etc/libvirt/ recently by any chance? It just seems odd to me that you would get those errors out of nowhere after a reboot.

yeah i did a mistake, sorry about that i ended up messing up qemu.conf inside /etc/libvirt to see if it w'd fix the dGPU binding problem but no, now its back to normal, with the output being pretty much the same as before.. Here, the corrected output of mbpt start if you wanna see: mbpt.sh_start_log.txt

The only caveat would be that you have to run it from a privileged terminal, but can't use sudo because sudo echo and >-redirecting will give you permission errors. Other than that I guess it should work, although I'm not sure if you might have to use /sys/bus/pci/drivers/vfio-pci/bind first.
You could try using ./scripts/utils/common/tools/driver-util --help which does both.

Hmm i searched on your scripts and /scripts/utils/common/tools/driver-util already indeed has these commands so i thought since it may do when starting the VM now i think thats not the problem when trying to bind the GPU unless ${DRIVER} doesn't get to the right directory because in my case instead of /sys/bus/pci/drivers/vfio-pci/bind it is called /sys/bus/pci/drivers/virtio-pci/bind,meaning vfio-pci doesnt exit and is instead virtio-pci, i don't really know about that for sure but i am leaving all inside the script by default to try make the least of a mess, i could still try doing it inside the terminal, but i think on your script does should do about the same no?

(*)->here is were i explain what i was talking about up in the top.
Now i've read this ##8 inside ur issue report session and i found some interesting points that could work for me, but before advancing to anything else i'd like to ask you if this sript works with nvidia PPA drivers and bumblebee loaded. I have bumblebee on my KDE distro and so far it doesnt work but maybe here it could work like on the guy that solved that same issue i have right now, i think it'd be worth a try :).

[T-vK]

I think it might be important to fix that dracut error because it is responsible for some of the vfio stuff:

MobilePassThrough/requirements.sh

Line 18 in 1527df2

KERNEL_PARAMS_GENERAL+=("rd.driver.pre=vfio-pci") # tell dracut to load vfio-pci first

Maybe you can try to google how to fix your dracut or maybe how to reset it.

It could explain why the vfio-pci driver and /sys/bus/pci/drivers/vfio-pci/bind seem to be missing on your system.

I used to automatically install and set up Bumblebee in earlier iterations of this project, but after adding support for AMD GPUs and making the project more distribution-agnostic it got too complicated for me. This is how I used to do it:

MobilePassThrough/utils/Fedora/34/bumblebee-setup

Lines 1 to 37 in 3e35715

	#!/usr/bin/env bash
	SCRIPT_DIR=$(cd "$(dirname "$0")"; pwd)
	PROJECT_DIR="${SCRIPT_DIR}/../../.."
	UTILS_DIR="${PROJECT_DIR}/utils"
	DISTRO=$("${UTILS_DIR}/distro-info")
	DISTRO_UTILS_DIR="${UTILS_DIR}/${DISTRO}"
	VM_FILES_DIR="${PROJECT_DIR}/vm-files"
	source "$DISTRO_UTILS_DIR/kernel-param-utils"
	echo "Disable Nouveau drivers"
	addKernelParam "nouveau.modeset=0"
	#sudo grep -qxsF 'blacklist nouveau' "/etc/modprobe.d/blacklist.conf" || echo "blacklist nouveau" | sudo tee -a "/etc/modprobe.d/blacklist.conf" > /dev/null
	#sudo grep -qxsF 'exclude=xorg-x11*' "/etc/dnf/dnf.conf" || echo "exclude=xorg-x11*" | sudo tee -a "/etc/dnf/dnf.conf" > /dev/null
	#sudo dnf remove xorg-x11-drv-nouveau -y
	echo "Install third party repositories"
	sudo dnf install fedora-workstation-repositories -y
	echo "Enable the Bumblebee repository"
	sudo dnf copr enable chenxiaolong/bumblebee -y
	echo "Install Bumblebee"
	sudo dnf install akmod-bbswitch bumblebee primus -y
	echo "Make Bumblebee avialable to the current user"
	sudo gpasswd -a $(who -m | awk '{print $1;}') bumblebee
	echo "Enable Bumblebee autostart"
	sudo systemctl enable bumblebeed
	echo "Block nvidia-fallback service"
	sudo systemctl mask nvidia-fallback
	echo "Start Bumblebee"
	sudo systemctl start bumblebeed

I'm not sure if it would still work, but maybe it does. Looking at vm.sh there still appears to be some code that was required to support Bumblebee:

MobilePassThrough/scripts/main/vm.sh

Lines 267 to 283 in 1527df2

	#####################################################################################
	################ Figure out if optirun or DRI_PRIME should be used ##################
	#####################################################################################
	function bumblebeeCheck() {
	if sudo which optirun &> /dev/null && sudo optirun echo > /dev/null ; then
	OPTIRUN_PREFIX="optirun "
	DRI_PRIME_PREFIX=""
	echo "> Bumblebee works fine on this system. Using optirun when necessary..."
	else
	OPTIRUN_PREFIX=""
	if [ "$SUPPORTS_DRI_PRIME" = true ]; then
	DRI_PRIME_PREFIX="DRI_PRIME=1 "
	else
	echo "> Bumblebee is not available..."
	fi
	fi
	}

Generally all drivers should be supported. I think I have tried radeon, amdgpu, nvidia and nouveau.

Edit: I think I forgot to answer your question regarding what happens if you bind to the vfio driver before the VM starts. For most notebooks (almost all in recent years) your screen and ports are fed by the frame buffer of the iGPU. This means even if you unbind the dGPU driver entirely, your screen wouldn't just go blank.
I always unbind the dGPU driver and then bind it to the vfio-pci driver before starting the VM btw. I haven't tried doing it the other way around. Sounds complicated and would probably require hotswapping. But it would be neat to be able to hand the dGPU back and forth between guest abd host without VM restarts.

[No-Biggie805]

I think it might be important to fix that dracut error because it is responsible for some of the vfio stuff:
MobilePassThrough/requirements.sh
Line 18 in 1527df2
KERNEL_PARAMS_GENERAL+=("rd.driver.pre=vfio-pci") # tell dracut to load vfio-pci first
Maybe you can try to google how to fix your dracut or maybe how to reset it.

Solved, i guess and to give credit were its due i found the solution here in case it helps somebody else: https://bugzilla.redhat.com/show_bug.cgi?id=1967457
from my understanding and as its mentioned right inside the discussion this seems to be Fedora's fault cause they remove some dependencies recently related to this, so now we have to install them, no hard feelings hahah its still a good distro.
Here is what dmesg shows now: Fixed_dratcut-logs.txt

But VFIO ain't cope with that, when i launched it the same error "/dev/vfio/1:no file or directory" came again, so well guess i am gonna advance to plan B, of Bumblebee+nvidia.

I'm not sure if it would still work, but maybe it does. Looking at vm.sh there still appears to be some code that was required to support Bumblebee:

Thank you for the explanation, and guidence so far, now it seems its up to me now, also one question about my dGPU, today i understood that a GPU without UEFI support makes process harder to do, did you ever had any success with gpu's of this kind?
I did passthrough it before right up my 1st attempt but only with a display manager like spice on kvm and code 43 came out. But we could do it no?

Edit: I think I forgot to answer your question regarding what happens if you bind to the vfio driver before the VM starts. For most notebooks (almost all in recent years) your screen and ports are fed by the frame buffer of the iGPU. This means even if you unbind the dGPU driver entirely, your screen wouldn't just go blank.

Neet B-), i always thought of something like that too since i know that specially cause in this PC when you install Win10 in order to run smooth even with dGPU drivers u need to install iGPU acceleration meaning even tho they disconected they still will work spareted just not quite like 2 VGA gpu's in a PC.

I always unbind the dGPU driver and then bind it to the vfio-pci driver before starting the VM btw.

Now that i remember i did too when following tut. on YT but using scripts, thats y i did not think that right lol. But ofc i did not have such succes doing a passthrough afterwards.

But it would be neat to be able to hand the dGPU back and forth between guest abd host without VM restarts.

Maybe in the future, for now really we need as a community to concentrate into getting a complete experience close to baremetal and doing it the easier way starting from the one you provide, install Win11 on it so then i won't need to worry by the year of 2025 when win10 ends for me to "forcefully" install it just so to get updates.. But really i feel like only want linux on my PC now.

Well will try keep you updated once i make any progress here, for now really no sucess..

[T-vK]

Great to hear that you managed to fix the dracut issue.
I suppose this was what fixed it for you?

sudo dnf install kbd-legacy
sudo dracut -f

I'm just asking because I should probably add this to the setup scripts so other people don't run into the same issue.

Now after fixing the dracut error and rebooting and running:

sudo modprobe vfio
sudo modprobe vfio_pci
sudo modprobe vfio_iommu_type1

is `/sys/bus/pci/drivers/vfio-pci´ still missing?

If it does exist now, it would be nice to see the output of:

sudo driverctl --nosave set-override "0000:01:00.0" vfio-pci

otherwise there is still a deeper issue going on with vfio. In that case I would like to start by checking your kernel parameters (cat /proc/cmdline).

Regarding Bumblebee, I'd advise you to first get it running without Bumblebee and once you got it, then try it with Bumblebee. I don't think that Bumblebee is going to simply things, but add a lot of complexity, potentially making it more difficult to find the root cause.

Regarding dGPUs that don't support UEFI, I haven't tried that yet. I think mbpt automatically creates UEFI-based VMs because the legacy method has a bunch of disadvantages and supporting both would complicate things a lot for me.

I think we have a very high chance of being able to work around Nvidias error 43 with mbpt.

[No-Biggie805]

Great to hear that you managed to fix the dracut issue.
I suppose this was what fixed it for you?

I only did:

• 1. Change KEYMAP in /etc/vconsole.conf to "us".
• 2. sudo dracut -f
     sudo dracut --regenerate-all --force
     From comment 1 in the discussion really, but if by any chance you could implement the two that w'd be really unless the one i used ofc really solves the problem for everyone, i'd advise you to try it to, to see any results yourself cause i am not confident enough to determine that for your project :,), sorry..

is `/sys/bus/pci/drivers/vfio-pci´ still missing?

Just executed the modprobe commands and checked afterwards, in the respective directory and yes now vfio-pci indeed exists now, with bind, unbind, module folder, new_id, remove_id, uevent and unbind, also alongside it "virtio-pci" under /sys/bus/pci/drivers still exists, hope it won't interfere with vfio..
After that $sudo driverctl --nosave set-override "0000:01:00.0" vfio-pci and after a password check takes some time and then it outputs Killed,i go check vfio-pci root folder and yes it still exits.
However from here i cannot restart the system without a force shutdown so i think here's is our reboot problem, do you know a command to revert vfio-pci set-override command after doing it? i'll try searching it too.
Also after rebooting vfio-pci still exits.

I still give you what i have inside cmdlide:

$ cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt6)/vmlinuz-5.16.18-100.fc34.x86_64 root=UUID=e7129ff9-fba7-4d13-bed9-3ce5e17aef01 ro rootflags=subvol=root rhgb quiet intel_iommu=on

Regarding Bumblebee, I'd advise you to first get it running without Bumblebee and once you got it, then try it with Bumblebee. I don't think that Bumblebee is going to simply things, but add a lot of complexity, potentially making it more difficult to find the root cause.

Makes sence, i'll save it for later then.

Regarding dGPUs that don't support UEFI, I haven't tried that yet. I think mbpt automatically creates UEFI-based VMs because the legacy method has a bunch of disadvantages and supporting both would complicate things a lot for me.

yeah idk either xp, we'll see then, i think we can do it based on what i already could before so. And thus surpass code 43.

[T-vK]

Alright, thanks for the info regarding dracut. :)

Glad to see you can finally load the vfio-pci driver. The virtio-pci driver is an entirely different driver that wouldn't interfere.

In order to revert the driver override, you can use:

MobilePassThrough/scripts/main/vm.sh

Line 931 in 1527df2

sudo driverctl --nosave unset-override "0000:${deviceAddress}"

(In your case with 0000:01:00.0 of course.)

Looking at your kernel parameters I'm a bit shocked. There are a lot of parameters missing that mbpt should have set for you.

Does mbpt setup throw any errors for you?

It should have set those 5 parameters found in here (not the amd one of course):

MobilePassThrough/requirements.sh

Lines 16 to 28 in 1527df2

	KERNEL_PARAMS_GENERAL=("iommu=1") # '1' is not a documented option. stop confusing me wendell! Maybe the "force" option should be used instead?
	KERNEL_PARAMS_GENERAL+=("kvm.ignore_msrs=1") # prevent bluescreens when a VM does MSR reads / writes directly
	KERNEL_PARAMS_GENERAL+=("rd.driver.pre=vfio-pci") # tell dracut to load vfio-pci first
	#KERNEL_PARAMS_GENERAL+=("pcie_acs_override=downstream") # fix /dev/vfio/1 not found error # shouldn't be necessary
	#KERNEL_PARAMS_GENERAL+=("acpi_osi=!") # may fix problems with AMI style UEFIs
	#KERNEL_PARAMS_GENERAL+=("acpi_osi='Windows 2009'") # may fix problems with AMI style UEFIs
	KERNEL_PARAMS_INTEL_CPU=("intel_iommu=on") # enable Intel VT-D ;# using "intel_iommu=on,igfx_off" iGPU gets no iommu group...
	#KERNEL_PARAMS_INTEL_CPU+=("915.preliminary_hw_support=1") # add skylake support; probably only necessary with older kernels
	KERNEL_PARAMS_AMD_CPU=("amd_iommu=on") # 'on' is not a docuemnted option for this parameter either! This is insanely confusing!
	KERNEL_PARAMS_INTEL_GPU=("i915.enable_gvt=1") # enable mediated iGPU passthrough support (GVT-g) on Intel iGPUs
	#KERNEL_PARAMS_AMD_GPU=()
	#KERNEL_PARAMS_NVIDIA_GPU=()
	#KERNEL_PARAMS_BUMBLEBEE_NVIDIA=("nouveau.modeset=0")

That could explain a lot of things, even the issue errors with your iGPU.

[No-Biggie805]

Alright, thanks for the info regarding dracut. :)

Glad i could help smh hehe.

In order to revert the driver override, you can use:
sudo driverctl --nosave unset-override "0000:${deviceAddress}"
(In your case with 0000:01:00.0 of course.)

Its not working, idk whats going on here,after doing sudo driverctl --nosave unset-override "0000:01:00.0",just hangs on the command line and to do anything else i need to force close it, killing the process,but then even if try again doing diferent combinations its all the same, i even did some search https://forums.developer.nvidia.com/t/cant-rebind-gpu-with-driverctl-if-system-booted-with-gpu-attached-to-nvidia-driver/191350 and https://forum.level1techs.com/t/problem-cant-use-driverctl-overrides-on-nvidia-driver/176777 for example aditionally and well maybe according to that i might do something wrong now, yet could i ask how you do it?Or what shows to you when you do it? To confirm if there's some bug on my system or something.. Thank you.
Again rebooting also still requires a force shut down as since it wont unset-override to bind the gpu back to nouveau..

Does mbpt setup throw any errors for you?

From what it showed me, no errors were found except when downloading ISO, which i doubt that could problem no?
Output: mbpt_setup.txt

It should have set those 5 parameters found in here (not the amd one of course):

Additionally here's what i have inside requirements.sh in a .txt: requirements_sh.txt

[T-vK]

We absolutely need to address the missing kernel parameters first. driverctl might very well just be failing because the kernel params are missing.

So mbpt setup thinks the kernel parameters are already set because they are in your /etc/default/grub file.

Try applying them like this:

./scripts/utils/manager-specific/kernelparams/grub apply

And then reboot to check if the parameters have been applied successfully by checking /proc/cmdline again.

If that didn't work can you tell me if you installed fedora in uefi or legacy mode?

[No-Biggie805]

./scripts/utils/manager-specific/kernelparams/grub apply

I ran it differently from what you asked but it changed the grub.
Here's the output of cmdline:

$ cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt6)/vmlinuz-5.16.18-100.fc34.x86_64 root=UUID=e7129ff9-fba7-4d13-bed9-3ce5e17aef01 ro rootflags=subvol=root i915.enable_gvt=1 amd_iommu=on rd.driver.pre=vfio-pci kvm.ignore_msrs=1 iommu=1 rhgb quiet intel_iommu=on iommu=pt

If that didn't work can you tell me if you installed fedora in uefi or legacy mode?

From what i notice its on UEFI really. On here https://itsfoss.com/check-uefi-or-bios/ i ran the command you see below and indeed it shows these respective folders.

$ ls /sys/firmware/efi
config_table  esrt              fw_vendor      runtime      systab
efivars       fw_platform_size  mok-variables  runtime-map

Also i tried ur modprobe commands on KDE neon and even though i couldn't have any sucess unseting the override and launch the VM it could at least reboot so maybe or either its a bug or mb we could be missing something like a blacklist of noveau? No?
On KDE i followed https://gist.github.com/Misairu-G/616f7b2756c488148b7309addc940b28 tut. but with some very minor adjustments so far.

[T-vK]

Now that the kernel parameters have been set correctly, can you try manually binding again using
/sys/bus/pci/drivers/vfio-pci/bind and /sys/bus/pci/drivers/vfio-pci/new_id ?

And check which driver is loaded in lspci then. It would also be worth it to check dmesg again, now that the kernel parameters are set.

I only tested mbpt with the default settings, usually on a fresh install. The only exception is installing the Nvidia proprietary driver, but other than that I haven't tested what happens when you change other configs.

It shouldn't matter if you use Gnome or KDE. I have tested it on a fresh install of the Fedora KDE spin before without problems.

But Ubuntu support with mbpt still pretty flaky. The automatic dependency installation doesn't work yet and there might other issues.

[No-Biggie805]

Sorry for the late response.. i ended up busy for the day.
Back to the point now in the meantime i did some noting on a notebook and following these commands on this website:https://forum.level1techs.com/t/need-help-with-dynamically-binding-and-un-binding-nvidia-gpu/154278/8, but doing mannualy, not on scripts ofc i still couldn't get any sucess binding GPU to vfio-pci and bind back to nouveau also. I really could only unbind the driver from nouveau.

Here's what happens.

• First it typed the modprobe commands;
• Then i entered root with sudo -i command;
• When unbind from nouveau sudo driverctl --nosave unset-override "0000:01:00.0" or echo '0000:01:00.0' > /sys/bus/pci/devices/0000:01:00.0/driver/unbind it does like normal with the output Killed. BTW after unbinding the content inside /sys/bus/pci/devices/0000:01:00.0/ disapears until i force reboot.
• But when trying to bind to vfio-pci echo '10de 13d8' > /sys/bus/pci/drivers/vfio-pci/new_id in here it hangs, and echo 0000:01:00.0 > /sys/bus/pci/drivers/vfio-pci/bind says -bash: echo: write error: No such device
• When trying to bind it back to nouveau echo 0000:01:00.0 > /sys/bus/pci/drivers/nouveau/bind it also hangs, and so from here to recover i need to force shut down and turn on again..

On lspci:

01:00.0 3D controller: NVIDIA Corporation GM204M [GeForce GTX 970M] (rev a1)
	Subsystem: CLEVO/KAPOK Computer Device 6555
	Flags: bus master, fast devsel, latency 0, IRQ 34, IOMMU group 1
	Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
	Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Memory at f0000000 (64-bit, prefetchable) [size=32M]
	I/O ports at e000 [size=128]
	Expansion ROM at f7000000 [disabled] [size=512K]
	Capabilities: [60] Power Management version 3
	Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [78] Express Endpoint, MSI 00
	Capabilities: [100] Virtual Channel
	Capabilities: [250] Latency Tolerance Reporting
	Capabilities: [258] L1 PM Substates
	Capabilities: [128] Power Budgeting <?>
	Capabilities: [420] Advanced Error Reporting
	Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
	Capabilities: [900] Secondary PCI Express
	Kernel modules: nouveau

Idk really whats going on here.. unlucky me if its my PC, sh*T.

[T-vK]

At this point I would advice you to try the mbpt live iso to rule out that it's a misconfiguration.
You can build the iso by running
./mbpt.sh live build 
It does however require a 64GB USB stick though if I recall correctly, otherwise it won't be able to install all the dependencies and create a vm etc.

Also, I hopefully fixed the Windows ISO download now, so booting from the stick should automatically create a GPU passthrough VM on the stick and install Windows in it.
If that works for you, then we know it's just a misconfiguration that's preventing it from working on your real system.

[No-Biggie805]

At this point I would advice you to try the mbpt live iso

One last question can you just tell me how to create the iso file inside another disk, like i have 2 local SDD's on my laptop and i intend to create it inside of the second onr since we are creating 64GB ISO am i right? And then flash with a imager inside an external HDD cause i got no pen drives big enough at hand..Wonder an HDD could still work really lmao.

Also did you try live ISO recently? because right before doing this in an installation it'd give me an issue regarded in this #26 type of issue.

[T-vK]

The ISO file itself is only going to be ~2.1GB in size. 64GB are required for when you boot it and it downloads Windows and creates a VM. I've never tried it on an HDD, but theoretically it should work.

You can flash it to using:

mbpt.sh live flash /dev/sdx

/dev/sdx being your USB stick, HDD or whichever device you want to use.

Regarding #26 that should be fixed with the commit I just pushed.

[No-Biggie805]

So by now i've been attempting to test the live build, and so i thought i could leave some update of what i've been attempting:

First flashing with mbpt.sh live flash /dev/sdx , i can't get it to work, i even tried specifying .iso folder location before the device to flash, and then including the mount and it'd give me an error: ERROR: At minimum, a source and a target must be specified. I believe this could be a syntax problem but i can't get it to work..
I Could however create a custom .iso file and flash with an imager (raspeberry pi and balena etcher used).

When launching the live build, on my laptop no sucess, first i had to launch without no UEFI boot, not a problem just saying, and then when running the script it gave some erros plus it just could not get the kernel params set up cause Virtualalization on this PC is not enabled on the bios it seems....
Unless there's a way to do it without opt inside the bios?? 0_0

So i went to plan B, using my decade old resurrected PC, so far i've tried live build on HDD as since i don't have 64Gb pen drive but it still needs a local drive to install the VM so it can be even my 8Gb pen drive, but even then its rough, kinda like a hit or miss, the script runs but for example when trying to open something to mannualy mount a drive to install the VM or opening up a browser to install the missing .iso, i can't open them.

But i went up to get all the configs right and so far it went up till failing to get to launch the VM due to not having a windows.iso, and so far i could not manage to put any myself.

Idk however if on my PC it w'd also work great too cause it only has a single GPU and without scripts it could also cause problems no?

[T-vK]

Try flashing it again using mbpt.sh live flash /dev/sdx, but instead of /dev/sdx use the device path of the device you want to flash the iso to. It will automatically search for the iso in the folder where it was generated.

You might want to run df -h in order to identify the device path you'd like to use.

The live version currently doesn't mount anything but the drive you boot it from. So it can only create the VM on that drive. I'll have to look into improving on that in the future.

The windows iso download should be fixed btw. If it is missing mbpt should automatically download a Windows 10 iso from Microsoft.

A PC with only one GPU will probably be problematic unless it has a dGPU and an iGPU. But even the, mbpt hasn't been tested very well on desktop PCs.

[No-Biggie805]

You might want to run df -h in order to identify the device path you'd like to use.

Find my hard drive:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           7.8G  184K  7.8G   1% /dev/shm
tmpfs           3.2G  2.0M  3.1G   1% /run
/dev/sda7        26G   20G  6.0G  77% /
tmpfs           7.8G   52K  7.8G   1% /tmp
/dev/sda7        26G   20G  6.0G  77% /home
/dev/sda6       976M  249M  661M  28% /boot
/dev/sda1        96M   47M   50M  49% /boot/efi
tmpfs           1.6G  124K  1.6G   1% /run/user/1000
/dev/sdc1       299G   96K  299G   1% /run/media/user/1711-2E61 -------------> HDD

Try flashing it again using mbpt.sh live flash /dev/sdx, but instead of /dev/sdx use the device path of the device you want to flash the iso to. It will automatically search for the iso in the folder where it was generated.

$ ./mbpt.sh live flash  /dev/sdc1 
[sudo] password for user: 
[Skipped] Executable dependencies are already installed.
[Skipped] livecd-tools already installed.
Flashing ISO to USB drive
/dev/sdc1 is still mounted.
Unmounting partition mounted at /run/media/user/1711-2E61...

    SYNTAX

    livecd-iso-to-disk [--help] [--noverify] [--format] [--msdos] [--reset-mbr]
                       [--efi] [--skipcopy] [--force] [--xo] [--xo-no-home]
                       [--timeout <duration>] [--totaltimeout <duration>]
                       [--nobootmsg] [--nomenu] [--extra-kernel-args <args>]
                       [--multi] [--livedir <dir>] [--compress]
                       [--skipcompress] [--no-overlay] [--overlayfs [temp]]
                       [--overlay-size-mb <size>] [--copy-overlay]
                       [--reset-overlay] [--home-size-mb <size>] [--copy-home]
                       [--delete-home] [--crypted-home] [--unencrypted-home]
                       [--swap-size-mb <size>] [--updates <updates.img>]
                       [--ks <kickstart>] [--label <label>]
                       <source> <target device>

    (Enter livecd-iso-to-disk --help on the command line for more information.)

Attempting same thing again still fails and then from here its were i tried also diferent combs., which also gave me the same error.

[T-vK]

I think you need to remove the number at the end.
/dev/sdc1 would be the first partition on your HDD and /dev/sdc would be the whole HDD.

[No-Biggie805]

I think you need to remove the number at the end. /dev/sdc1 would be the first partition on your HDD and /dev/sdc would be the whole HDD.

Now i ended up updating the repository, only 7 hours after seeing you updating, cleared some storage a currently i have 12Gb on my main SSD, and tried again:
for /dev/sdc/ :live_logs.txt
and /dev/sdc1/ : live_logs_1.txt

But still no success thus far, the same issue comes over again, does it appear for you on your tests?

[T-vK]

Sorry for all the issues. I will try to reproduce and figure out where this error is coming from tomorrow.

[No-Biggie805]

Sorry for all the issues. I will try to reproduce and figure out where this error is coming from tomorrow.

No problem, i will keep workin on my end too and give any news in case i succed.

Btw On KDE neon btw lspci v when i bind to vfio does show that it is connected to vfio driver, with other modules loaded but i can t lauch the VM, mb because of old nvidia drivers? Idk but that could mean something, that theres hope for sure!

[T-vK]

That is good news indeed, there is definitely hope. :)
I don't think it matters which driver you use. I got it working with all sorts of different drivers in the past. And since the driver is literally not talking to the GPU anymore as soon as you unbind it, the only driver that would matter would be vfio-pci.

I just pushed another commit fixing a bunch of things. There were a few bugs and one of them was that an incompatible version of livecd-tools was installed into the ./thirdparty directory. I would advise you to delete that directory and run ./mbpt.sh setup again, then you should rebuild the mbpt iso by running ./mbpt.sh live build and finally the flashing should work fine: ./mbpt.sh live flash /dev/sdx (The device path definitely needs to be without the digit in the end btw.)

[No-Biggie805]

Sorry i took a while unfornatly i lost access to the linux distros, grub in reorvery mode, no way to recover it.. and had to wipe both fedora and kde away, now i am back with Fedora 34.
And i gotta say i am impressed indeed i already tested live flash and it worked great only thing is that it sill ended up in /dev/vfio/1: no such file or directory problem so that means really i need something like bumblebee in order for it to unbind from the default driver and bind it to vfio.
Appart from that it instaled everything, configurated the VM and if wasn't for that problem it'd probably just work.

Heres the whole replicate of what happened:replicate.txt

[T-vK]

I just found something interesting that I must have forgotten about.
Can you try uncommenting this line:

MobilePassThrough/requirements.sh

Line 19 in da8c37e

#KERNEL_PARAMS_GENERAL+=("pcie_acs_override=downstream") # fix /dev/vfio/1 not found error # shouldn't be necessary

Then run ./mbpt.sh setup again, reboot and see if that fixes it?

[No-Biggie805]

I just found something interesting that I must have forgotten about. Can you try uncommenting this line:

MobilePassThrough/requirements.sh

Line 19 in da8c37e

#KERNEL_PARAMS_GENERAL+=("pcie_acs_override=downstream") # fix /dev/vfio/1 not found error # shouldn't be necessary

Then run ./mbpt.sh setup again, reboot and see if that fixes it?

Tried it but it did not work, i removed the comment:
requirements.txt
Also tried flashing afterwards and it did not do anything cause yeah it gets from the repository from the internet and as i couldn't find the folder i did not have any way to try, /dev/vfio/1:folder not found problem still appears.

Also i tried from your other branch were your script installs bumblebee and nvidia but seemed to not work, issue due to not finding the device, you will see later in the file but its bound to vfio currently, this was also a issue when i tried on KDE it seems but i quite don't understand this problem really, so i don't think neither bumblebee(or is it?) and nvidia are malfunctioning, but one thing, could you tell me from where is it trying to find the device? If it is in this format echo '0000:01:00.0' > /sys/bus/pci/devices/0000:01:00.0/driver/bind then it really is the same problem or no, i don't quite remember really so would really need to have a check in order to find out perhaps.
Also iGPU gives an error and i am not sure if it too tries to prevent me from continuing, i tried to disable SHARE_IGPU param inside default.conf but seems like it did not fall for that same trick, i commented on start_vm.sh but no results there either.

Leaving my outputs if you wanna see:
default mbpt.sh start: mbpt.sh_start.txt
lspci after loading the VM with default configs:lspci -v.txt

After commenting on VM and setting iGPU:
start_vm.sh : start.txt
mbpt.sh start :
lspci -v before:
lspci -v after:

Lastly as i was experimenting with different configs i also saw there was “user.conf” and as you mentioned before this is an easy way to enable/disable iGPU passthrough, i also uncommented the settings inside start_vm.sh, so i did it together with default.conf igpu_share set to false and here again are my results.

mbpt_sh start:
user_conf_igpufalse_vmlauch.txt

lspci -v show the same as before now

My overall impression is that doing this way my PC just works better,rebooting works fine, bind and unbind also works, kinda, but the whole setup in order to work still requires some further tweaks, i am up to even learn a bit of bash just to see if i can configure all here, i don't want to have you do all the work really, but yeah i am a total noob in this regard. But for this PC it really needs a switcher to bind/unbind gpus cause the default way for this here will cause instability and malfuntions requiring some force shutdowns.
From what i can see really these problems seem similiar to the ones found in discussion 8 in your repository, it will be hard for me in the case as i am not specialized on bash but yeah i think at least from there its were i see related reports.

Update: On main branch now lauching the VM it starts without looking glass yet, but it binds to vfio now at least, i can't yet boot to windows, will have to try putting an .iso or something.

Update 2: installed windows inside the VM, the script did it automatically and all the scripts were installed too i also in this instalation changed the password(will probably reenstall afterwards), however the display acceleration seem to not be enabled i tried getting virtio drivers for windows and they did not install here.. what am i missing here?

[T-vK]

Sorry for the late response. I'm a bit busy at the moment.

I think the folder is created in /run/initramfs/live/mbpt/MobilePassThrough on the live version.

could you tell me from where is it trying to find the device? If it is in this format echo '0000:01:00.0' > /sys/bus/pci/devices/0000:01:00.0/driver/bind then it really is the same problem or no, i don't quite remember really so would really need to have a check in order to find out perhaps.

I don't understand what you mean. It finds the device using lspci I think.

Also iGPU gives an error and i am not sure if it too tries to prevent me from continuing, i tried to disable SHARE_IGPU param inside default.conf but seems like it did not fall for that same trick, i commented on start_vm.sh but no results there either.

default.conf should always be left untouched. If you want to make modifications, you can create a user.conf with the same content and modify that. If there is a user.conf it will always use that instead of the default.conf.
Your user.conf seems to be corrupt in some way. Can you share the content of that file?
There is something wrong with the VM_FILES_DIR variable and other variables seem to be missing as well. Maybe you accidentally used a .conf file from the old Branch which is not compatible with the current one.

Once you get that fixed, there is no need to modify the vm.sh to not use the iGPU.

Update: On main branch now lauching the VM it starts without looking glass yet, but it binds to vfio now at least, i can't yet boot to windows, will have to try putting an .iso or something.

Yeah, Looking Glass is not very reliable at the moment. Also RDP support is a bit flaky as well since Remmina changed a bit.

however the display acceleration seem to not be enabled i tried getting virtio drivers for windows and they did not install here.. what am i missing here?

I'm not entirely sure, but it should have installed the virtio drivers automatically from the generated helper iso in vm-files/mobile-passthrough-helper.iso. Specifically this Batch script:

MobilePassThrough/helper-iso-files/mbpt-helper.bat

Lines 12 to 14 in 7102471

	echo "Install vfio drivers..."
	certutil -addstore "TrustedPublisher" .\RedHat.cer
	%WINDIR%\system32\pnputil.exe /add-driver .\bin\virtio-drivers\Win10\amd64\*.inf /subdirs /install

[No-Biggie805]

Sorry for the late response. I'm a bit busy at the moment.

No problem, really you have been enough help really thanks to you i learned a lot and now i even am enough confident to build a VM myself if anything happens here.

I think its fair to first tell you my status, so for now GPU passthrough is working with your scripts, but with a bit of a mix of configs, though i believe from what i have thats being used from your unnatained-win-install is bumblebee and nvidia drivers. Then i ran the script from the main branch, made the installation first and then it ran pretty well no error code 43, Now some times after when rebooting doing a boot the OS gets stuck so that way i need to ctrl alt del and then bam it runs back again.
The VM starts and stops without really needing to reboot the Host, but GPU utilization sits at 0% all the time and according the registers its only utilizing the CPU.. I found in a video on were i discussed on there too, that in order for the dGPU to render i need to to have it connected to a display, but my HDMI is only connected to the iGPU and saw on reddit that in many cases mini displayports are connected to the dGPU, so i ordered an adapter, expecting it within a month.. or more, and then hopefully it works.
Another thing i could try doing is maybe connecting ti a virtual display if that is possible, is it? Think it works on looking glass at least??
All in all i hope this is my issue rn.. And makes much sence tbh.

So yeah it will be quite the work or just patience alone.

I'm not entirely sure, but it should have installed the virtio drivers automatically from the generated helper iso in vm-files/mobile-passthrough-helper.iso. Specifically this Batch script:

Yes i checked it later and indeed it is instaled. I have now no idea what else could appart from it being the dGPU not connected to a display.

[T-vK]

Thanks for the update, glad to hear you got it working somehow. :)
It's not quite clear to me when you are talking about the host and when you are talking about the guest. I'm jsut assuming your GPU utilization issues are on the host. Did you try running the application with optirun (in case you're using Bumblebee) or DRI_PRIME=1 (if you're not using Bumblebee)?

About the virtual display, it probably depends on what kind of virtual display it is. There is the one that can be created via dma-buf which might not be available on your CPU and there is the QXL one which is created for the spice client during the installation process and then there is the one Windows creates when an RDP connection is established. And finally there are external dummy adapters that you can plug into a physical port to make the OS think there is a real display connected.

[No-Biggie805]

Thanks for the update, glad to hear you got it working somehow. :) It's not quite clear to me when you are talking about the host and when you are talking about the guest. I'm jsut assuming your GPU utilization issues are on the host. Did you try running the application with optirun (in case you're using Bumblebee) or DRI_PRIME=1 (if you're not using Bumblebee)?

My apology, so much to try being specific and at the end i failed specifiyng from where it was, by issues on gpu utilization i meant on the guest i'll leave below a picture of what happens, also optirun can fail sometimes too i just now on my 1st attempt booting the OS and then starting the VM it failed giving me the usual /dev/vfio/1: file missing, after that another reboot and worked again so its 100% not there but its fine, its pretty doable.
Here's a picture of my guest system kinda:

You can see the CPU at 100% and GPU polishing some nails haha, this is more noticiable when playing a game btw, also resolution is set to 800x600 locked.

About the virtual display, it probably depends on what kind of virtual display it is. There is the one that can be created via dma-buf which might not be available on your CPU

Let me guess the lack of intel-GVTg support? I can not really see any other reason it could it could prevent the DMA buffer from acessing to the system, am i right? Sorry i did only a quick search and did not really understand what it does specifically since the wiki generalized a bit. I found info on that in here:https://01.org/linuxgraphics/gfx-docs/drm/driver-api/dma-buf.html

and there is the QXL one which is created for the spice client during the installation process

Might this be the only way really.. here, i have logs from using my VM after a start and then closing it:
mbpt_start.txt
it says that its disabled so we could maybe try and enable it.

and then there is the one Windows creates when an RDP connection is established

that one works, never tried gaming but its not like using one that the system uses by itself, animations are disabled and so might be any 3D rendering.

And finally there are external dummy adapters that you can plug into a physical port to make the OS think there is a real
display connected.

Yeah that might be my last hope from what i can see for now, well at least i made a GPU passthrough, just out of curiosity did you ever try doing it with your script? even through HDMI or something?

[T-vK]

By default, display-mode-4 is used:

MobilePassThrough/scripts/utils/common/plugins/display-mode-4

Lines 8 to 22 in 7102471

	USE_LOOKING_GLASS=false
	if [ "$VM_ACTION" = "start" ]; then
	USE_RDP=true
	elif [ "$VM_ACTION" = "install" ]; then
	USE_RDP=false
	fi
	if [ "$DMA_BUF_AVAILABLE" = true ]; then
	USE_QXL=false
	USE_DMA_BUF=true
	else
	USE_DMA_BUF=false
	USE_RDP=true
	fi

Basically, if dma-buf is available, it uses dma-buf, otherwise it'll use qxl.

I'm not 100% sure that your CPU doesn't support gvt-g and dma-buf. I think there are different versions of it and maybe your CPU just supports an older version that I might have to add support for. Can you run the following:

sudo modprobe kvmgt #sudo modprobe xengt
sudo modprobe vfio-mdev
sudo modprobe vfio-iommu-type1

and then check if there is anything in this directory? /sys/bus/pci/devices/0000:${IGPU_PCI_ADDRESS}/mdev_supported_types

Yeah that might be my last hope from what i can see for now, well at least i made a GPU passthrough, just out of curiosity did you ever try doing it with your script? even through HDMI or something?

I have used those dummy plugs a few years ago, but I'm not sure why exactly I needed them. I think it was on a notebook that wasn't muxed.

[No-Biggie805]

Basically, if dma-buf is available, it uses dma-buf, otherwise it'll use qxl.

No qxl option is there so i suppose the code does it by itself right? w'd it be wise to put qxl=true there though or is it just redundant?

I'm not 100% sure that your CPU doesn't support gvt-g and dma-buf. I think there are different versions of it and maybe your CPU just supports an older version that I might have to add support for. Can you run the following:
sudo modprobe kvmgt #sudo modprobe xengt
sudo modprobe vfio-mdev
sudo modprobe vfio-iommu-type1

So i ran it and gave me some errors.
output:compatible_check.txt

My iGPU adress:

00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller])
	Subsystem: CLEVO/KAPOK Computer Device 6555
	Flags: bus master, fast devsel, latency 0, IRQ 34, IOMMU group 2
	Memory at f7400000 (64-bit, non-prefetchable) [size=4M]
	Memory at d0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at f000 [size=64]
	Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: i915
	Kernel modules: i915

in the directories:
before:

After:

I have used those dummy plugs a few years ago, but I'm not sure why exactly I needed them. I think it was on a notebook that wasn't muxed.

Is it really necessary, for it to render at 1080p or w'd a connection directly on to the dGPU work, like i intend with a simple mini dp adapter? Also would that work if connected to a screen through the iGPU even if the iGPU is not passing through. Sorry for the many questions its just this is all so niche and complicated..

[T-vK]

Okay and i915.enable_gvt=1 is still in your /proc/cmdline, right? In that case I would say gvt-g is not supported and thus dma-buf isn't available either.

Is it really necessary, for it to render at 1080p or w'd a connection directly on to the dGPU work, like i intend with a simple mini dp adapter?
I don't understand your question.

Also would that work if connected to a screen through the iGPU even if the iGPU is not passing through.
I don't understand that question either.

No qxl option is there so i suppose the code does it by itself right? w'd it be wise to put qxl=true there though or is it just redundant?
Looking at display-mode-4 again, forget what I said regarding QXL. That mode only enables QXL during the installation.
You could try display-mode-3. That one should enable QXL and Looking Glass, but I suspect that looking glass won't work at the moment. You could create a new display mode by creating ./scripts/utils/common/plugins/display-mode-6 with this content:

#####################################################################################################
# This script has to be sourced and is not meant to be executed directly!
# It sets the display output configuration.
# How to use:
# source "$PLUGIN_DIR/display-mode-x"
#####################################################################################################

USE_LOOKING_GLASS=false
USE_SPICE_CLIENT=true

if [ "$DMA_BUF_AVAILABLE" = true ]; then
    USE_DMA_BUF=true
    USE_QXL=false
else
    USE_DMA_BUF=false
    USE_QXL=true
fi

if [ "$VM_ACTION" = "install" ]; then
    USE_RDP=false
else
    USE_RDP=true
fi

And then change your user.conf to use that new display mode.

[No-Biggie805]

Okay and i915.enable_gvt=1 is still in your /proc/cmdline, right? In that case I would say gvt-g is not supported and thus dma-buf isn't available either.

$ cat /proc/cmdline 
BOOT_IMAGE=(hd0,gpt5)/vmlinuz-5.16.20-100.fc34.x86_64 root=UUID=a7ea3540-04c2-4b70-b4c3-2c4fed65fd7a ro rootflags=subvol=root i915.enable_gvt=1 amd_iommu=on intel_iommu=on rd.driver.pre=vfio-pci kvm.ignore_msrs=1 iommu=1 rhgb quiet rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1

If i am right this is the grub configuration from "unnatained-win-install" branch too. But yeah the VM i am using is from the "main" branch already, to not confund.

Is it really necessary, for it to render at 1080p or w'd a connection directly on to the dGPU work, like i intend with a simple mini dp adapter?
I don't understand your question.
Also would that work if connected to a screen through the iGPU even if the iGPU is not passing through.
I don't understand that question either.

Never mind, regarding the Dummy adapter i think i finally understood what it does and for what its needed for.
My question was whether i could or not turn display to 1080P resolution but think i got the anwser already while testing with QXL xd.

Looking at display-mode-4 again, forget what I said regarding QXL. That mode only enables QXL during the installation.
You could try display-mode-3. That one should enable QXL and Looking Glass, but I suspect that looking glass won't work at the moment. You could create a new display mode by creating ./scripts/utils/common/plugins/display-mode-6 with this content:

So first and foremost after checking the files and content inside them, i created new user.conf file and edited from there like you said some days ago and first tried display-3, it worked great but looking glass indeed did not want to, showing only the purple window with its logo meaning no windows display was working, then i created display-6 with the content you provided and changed again inside user.conf and yeah QXL worked great, resolution changed sucessfully too but yeah performance was worse than with spice alone, now its 2x screens and one being at 1080p, thus CPU was still being the only one utilized really so that means only missing thing to do is connecting to the dGPU.

[T-vK]

Okay I think it's safe to assume then that gvt-g is not available on your CPU.

I don't know if connecting a display to one of the ports is really gonna help. I'm just skeptical about one of the ports being wired directly to the dGPU, but I would love to be proven wrong. Theoretically there should be a way to solve this in software, maybe there is some sort of Windows application that can force other applications to use the dGPU.

[No-Biggie805]

Okay I think it's safe to assume then that gvt-g is not available on your CPU.

The sad truth really, i even tried to see if messing up on user.conf, setting up iGPU passthrough to auto to see if it w'd work but no, it gave me the modprobe: ERROR: could not insert 'kvmgt': No such device error. I did some further search and this is not related in my case but seems that also only from 5th gen to 9th gen intel gvt-g is supported.. meanwhile they created gvt-d and now they are pulling SR-IOV support,gvt-g again seems to not be supported, this technology came a long way already, but for us really is a headache to allways deal with these changes.. Best is to rely on dGPU alone and one that we know thats connected to a video out port.

I don't know if connecting a display to one of the ports is really gonna help. I'm just skeptical about one of the ports being wired directly to the dGPU, but I would love to be proven wrong.

Yeah its a 5050 chance to work really.. I am more than enough happy to see this passing through the dGPU though. But if it doesn't then i might consider selling this one and upgrading to a new one, however it seems i can't choose anything equal or below 50 series card like 3050 cause manufacturers seem to not put video out there.. it will be quite the investment tho, in order to buy one for something like this.
source:https://lantian.pub/en/article/modify-computer/laptop-muxed-nvidia-passthrough.lantian/

Theoretically there should be a way to solve this in software, maybe there is some sort of Windows application that can force other applications to use the dGPU.

Will have a look then but i hardly believe there's such a thing on windows ahha more could i expect to have a solution from the linux side but again with no gvt-g then its pretty much null from there too..

Will leave any updates if anything works out, if not then i close the issue because for current status your repository works really well except that on my PC it decided to bitch out at the end kek.