bhyve Is there a method to understand inside which FreeBSD branch does my vmm.ko file come from ?

I'm not sure at all that this is the right solution. Why ? Because bhyve is integrated within the OS. The packages below can't be locked :

vmm.ko
bhyve
bhyvectl
bhyveload

because those files aren't packages and aren't in the repository.

and most important,I can't lock the kernel itself. If I lock it,I can't upgrade the system anymore,because the recompilation of the kernel is often needed. And when this happens,probably the bhyve system is changed and the new change will break the passthru function.
 
NapoleonWils0n said:
sounds like you either upgrade and break you set up
or dont upgrade
Click to expand...

Not every upgrade of the system breaks the passthru. I keep the bhyve files that are working saved in a safe place. So,when I upgrade the packages and the passthru stop working,I exchange the new files added with the older ones and it restarts working. But if the kernel is recompiled,it becomes a mess,the passthru may stop working and I don't know what to do.
 
ziomario said:
Today I've upgraded the packages and the passthru stopped working. Maybe because bhyve and some other components have been changed and the kernel has been recompiled.
Click to expand...
Describe *exactly* what happens.

Note that on restarting a VM sometime a board not be in a good state. I have had to do things like "devctl reset -d pci0:0:7:0" on the guest and sometime even on the host and restart.
 
On FreeBSD 14.0 I can passthru my GPU correctly. After having upgraded it to 14.1,bhyve does not work anymore. The error that it gives when I try to create a vm is : vm_create: No such file or directory. I see that it is not able to load the vmm.ko module,that's because the one that works belongs to 14.0. Below you can read the whole log of the upgrade from 14.0 to 14.1 :

Ubuntu Pastebin

paste.ubuntu.com paste.ubuntu.com

This is the log of dmesg of the 14.1 :

Ubuntu Pastebin

paste.ubuntu.com paste.ubuntu.com
 
Basically : is it normal that the vmm.ko module created for 14.0 can't be loaded in 14.1 ? I've reinstalled 14.1 from scratch. It has its own vmm.ko module,but it is not able to passthru my gpu. But the module for 14.0 can do it. So,what should I do ? Am I tied to 14.0 forever ?
 
i would think that modules only work on the version of Freebsd that they were built for

So the only thing you could do is file a bug report about the issue
And then wait until it gets fix and then upgrade

If Windows is that important might be better to install it on another machine if you have one
rather than using bhyve with gpu pass through
 
Yeah,users who can't or don't want to dual boot exist for a lot of reasons. I don't like Windows,but sometimes it is needed. But dual boot is never wanted.
 
This is the error that it gives when I try to load on 14.1 the vmm.ko module that belong to 14.0 :

Code: 
root@marietto /boot/kernel]==> kldload vmm.ko
kldload: can't load vmm.ko: module already loaded or in kernel

is there a method to load it ? It is telling a lie,the module hasn't been loaded :

Code: 
[root@marietto /boot/kernel]==> kldstat | grep vmm
nothing.

I'm ignorant,but that module has been added inside the kernel config file ? Should I recompile the kernel removing it ?
 
you can install windows on an external usb drive and boot from that

by converting a qemu windows.qcow2 file and install it onto the an external drive
i did it years ago and it works like a charm

Code: 
qemu-img convert windows.qcow2 -O raw /dev/sdb
 
NapoleonWils0n said:
you can install windows on an external usb drive and boot from that

by converting a qemu windows.qcow2 file and install it onto the an external drive
i did it years ago and it works like a charm

Code: 
qemu-img convert windows.qcow2 -O raw /dev/sdb
Click to expand...
Can this be done without qemu? bhyve generally use disk.img, can we do something like below
Code: 
dd if=disk0.img of=/dev/sdb bs=1M conv=sync
 
NapoleonWils0n said:
you can install windows on an external usb drive and boot from that

by converting a qemu windows.qcow2 file and install it onto the an external drive
i did it years ago and it works like a charm

Code: 
qemu-img convert windows.qcow2 -O raw /dev/sdb
Click to expand...

The point of this discussion is not to install Windows on a external drive and boot from that,but to be able to pass thru my GPU inside the Windows VM and to do that,I need to load the vmm.ko module of 14.0 to 14.1. Please don't deviate from the focus of this thread. thanks.
 
The vmm.ko module which works has been given to me by a reddit user,but later I found that it is in the branch of the 14.0,so what I did has been to install the 14.0. On my 14.0 system I can load it and unload it. The problem arises when I have upgraded 14.0 to 14.1 using the freebsd-update script. I suspect that that method embedded the (wrong) module inside the kernel config file. What I want to know now is : should I recompile the kernel declaring that I want to load that module using the loader.conf file ? how can I do this ? The problem seems to be that I can't use the freebsd-update script. But which other method can I use to upgrade 14.0 to 14.1 if I want to have a vmm.ko module that I can load using loader.conf ? Maybe 14.1 is able to accept the module of 14.0,but if there is another module embedded,I can't try.
 
Can I use this method ?

Code: 
# setenv  EDITOR  /usr/local/bin/nano
# setenv  VISUAL  /usr/local/bin/nano
# cd /usr
# mv src src-old
# git clone https://git.FreeBSD.org/src.git /usr/src
# cd /usr/src
# git checkout releng/14.1
# make -j4 buildworld
# make -j4 kernel
# shutdown -r now
# etcupdate -p
# cd /usr/src
# make installworld
# etcupdate -B
# shutdown -r now
# etcupdate resolve
 
ziomario said:
Please explain a little bit more. Thanks.
Click to expand...

Instead of getting a compiled binary of the offending module you should have gotten the patch ("diff"erence to the official source code). Then you could apply it to the 14.1 source code and everything would be peachy.

I thought we clarified this months ago?
 
ziomario said:
This is the error that it gives when I try to load on 14.1 the vmm.ko module that belong to 14.0 :

Code: 
root@marietto /boot/kernel]==> kldload vmm.ko
kldload: can't load vmm.ko: module already loaded or in kernel
is there a method to load it ? It is telling a lie,the module hasn't been loaded :

Code: 
[root@marietto /boot/kernel]==> kldstat | grep vmm
nothing.
Click to expand...

The message kldload: can't load vmm.ko: module already loaded or in kernel trying to load 14.0 vmm.ko on 14.1 is misleading.

Look in the system console (tty0, Alt+F1), dmesg(8) or /var/log/messages. There should be a report about kernel version mismatch.

There is no method to load a kernel module build against a specific kernel version (14.0) on another kernel version (14.1). Forget what those on reddit are saying in your thread, it's nonsense.

ziomario said:
The problem arises when I have upgraded 14.0 to 14.1 using the freebsd-update script. I suspect that that method embedded the (wrong) module inside the kernel config file.
Click to expand...
Not sure what you mean by "embedded the (wrong) module inside the kernel config file", but it's unlikely that a 14.0 kernel module was installed in a 14.1 upgrade by freebsd-update(8). More likely, given the fact you configure your system in unusual, unsupported ways, it was placed by yourself.

ziomario said:
Sorry,I haven't a clear idea about how to do what you are suggesting.
Click to expand...
You mention on r/freebsd a "trick (or the patch)". What was the trick or patch? If there is a patch maybe it can be applied on 14.1.

ziomario said:
should I recompile the kernel declaring that I want to load that module using the loader.conf file ?
Click to expand...
The GENERIC kernel comes already with vmm.ko as a module ready for loader.conf, no special configuration needed. With the right vmm.ko compiled against the same kernel it is loaded under, setting it in loader.conf to auto-load on system boot is no problem.

There is always the PR path to your issue: https://bugs.freebsd.org.
 
T-Daemon said:
There is no method to load a kernel module build against a specific kernel version (14.0) on another kernel version (14.1). Forget what those on reddit are saying in your thread, it's nonsense.
Click to expand...

This is a message shown on the FreeBSD ML some days ago :

I have reading some resources regarding FreeBSD drivers, looks like FreeBSD has a superior system to Linux's Dynamic Kernel Module System (dmks), for loading drivers, as by the architecture book (https://download.freebsd.org/doc/en/books/arch-handbook/arch-handbook_en.pdf, or in other of the sources at freebsd.org I don't remember exactly) it does allow to use loadable kernel drivers between different version of the FreeBSD kernel, giving both backwards and forward compatibility by design, through an stable Binary Application Interface.
Click to expand...
 
You must log in or register to reply here.
Back
Top