Solved Trying to understand why only some kind of vmm.ko module allows to passthru my nvidia GPU to a WIndows 11 vm

ziomario said:
bileslav : I want to clarify that I never thought that you did something of malicious with the files that you gave to me. I suspect that,in some way,the vmm.ko file that you gave to me cannot be found in the FreeBSD servers and it can't be replicated because there are some differences between your and my machine,for example...or from your system and mine,even if we ran the same FreeBSD version. Maybe this is totally wrong,but I think its legit to think it unless someone more experienced than me tell that it can't be. Anyway,my researches aren't finished yet and maybe I will find it.
Click to expand...
The FreeBSD installer and freebsd-update do not extract anything depending on the machine. At a certain point in time, it's the same set of files for everyone. And you convinced yourself of this when you found “my” vmm.ko in a freshly installed (and upgraded, it seems) VM during our correspondence on Reddit. However, now, after time and updates, finding exactly that version (commit?) of FreeBSD is a real challenge, apparently. But it surely exists. Good luck with your search, I believe this should lead somewhere.
 
This is the values that it found for the working vmm.ko :

Code: 
[root@marietto /boot/kernel]==> size vmm.ko

   text       data        bss        dec        hex    filename
 181732      31048    3186760    3399540     33df74    vmm.ko

what's the other vmm.ko that I should compare with the first one ?
 
This is the vmm.ko that comes from the 14.0-RELEASE-p6 #15 :

Code: 
[root@marietto /mnt/ada2p2/boot/kernel_d338712beb16ad7740bbd00bd93299a131a68045-p6_15]==> size vmm.ko

   text       data        bss        dec        hex    filename
 181732      31048    3186760    3399540     33df74    vmm.ko
 
They are identical !!!! but the first one works,the second one does not work !!! can this be possible ???? there could be some differences that we still don't see ???

A suspect is coming to my mind. The files can be really identical,but the working one can "touch" some part of the system that the second one can't touch ???? But in this case,they can't be identical,anyway.
 
I don't know if it is relevant or not,but I can always recognize the vmm.ko that works,because its creation and modification date (04.03.2024) never change. If it changes (like the vmm.ko on the right of the picture) it will not work.

Istantanea_2024-07-11_03-36-10.jpg
 
Cath O'Deray said:
Not patch level 6.

ziomario you'll find 06497fb on the FreshBSD page that I gave you on Wednesday morning. Please follow the link; it's for patch level 2.

Thanks.
Click to expand...

Code: 
[root@marietto /mnt/ada2p2/boot/kernel_06497fbd52e2f138b7d590c8499d9cebad182850]==> size vmm.ko

   text       data        bss        dec        hex    filename
 181732      31048    3186760    3399540     33df74    vmm.ko
 
It seems again the same as the working file,but its creation and modification date is different,so it will not work.
 
Hmmm....

Code: 
-notworking_vmm.ko:     file format elf64-x86-64-freebsd
+working_vmm.ko:     file format elf64-x86-64-freebsd
 
 
 Disassembly of section .text:
@@ -12692,9 +12692,9 @@
     b3ae:      41 81 fc ff ff ff 3f    cmp    $0x3fffffff,%r12d
     b3b5:      76 1c                   jbe    b3d3 <x86_emulate_cpuid+0x73>
     b3b7:      41 b9 00 00 00 40       mov    $0x40000000,%r9d
-    b3bd:      bb 62 68 79 76          mov    $0x76796862,%ebx
-    b3c2:      41 bf 65 20 62 68       mov    $0x68622065,%r15d
-    b3c8:      41 b8 79 76 65 20       mov    $0x20657679,%r8d
+    b3bd:      bb 4b 56 4d 4b          mov    $0x4b4d564b,%ebx
+    b3c2:      41 bf 56 4d 4b 56       mov    $0x564b4d56,%r15d
+    b3c8:      41 b8 4d 00 00 00       mov    $0x4d,%r8d
     b3ce:      e9 61 05 00 00          jmp    b934 <x86_emulate_cpuid+0x5d4>
     b3d3:      8b 0d 00 00 00 00       mov    0x0(%rip),%ecx        # b3d9 <x86_emulate_cpuid+0x79>
     b3d9:      44 39 e1                cmp    %r12d,%ecx

Same, but not unified.

Code: 
~(joker)540% diff *.asm
2c2
< notworking_vmm.ko:     file format elf64-x86-64-freebsd
---
> working_vmm.ko:     file format elf64-x86-64-freebsd
12695,12697c12695,12697
<     b3bd:     bb 62 68 79 76          mov    $0x76796862,%ebx
<     b3c2:     41 bf 65 20 62 68       mov    $0x68622065,%r15d
<     b3c8:     41 b8 79 76 65 20       mov    $0x20657679,%r8d
---
>     b3bd:     bb 4b 56 4d 4b          mov    $0x4b4d564b,%ebx
>     b3c2:     41 bf 56 4d 4b 56       mov    $0x564b4d56,%r15d
>     b3c8:     41 b8 4d 00 00 00       mov    $0x4d,%r8d
 
It's becoming interesting...does it mean that the working file cointains some kind of function or patch that the other one does not have ?
 
Here, with an updated temporary test machine (an old MacBook Pro):

Code: 
Script started on Thu Jul 11 01:56:02 2024
root@patchy:/boot/kernel # openssl sha256 ./vmm.ko

SHA2-256(./vmm.ko)= 42b3b7d004738e8b590d147e954ab17a887f789e615741f99215042d2edbc06e
root@patchy:/boot/kernel # openssl sha256 ../kernel.GENERIC-MMCCAM/vmm.ko

SHA2-256(../kernel.GENERIC-MMCCAM/vmm.ko)= 627fdd44f3d2ee2f99d44c48c13b58e2151c8a64010f51ee485e7f83285288d7
root@patchy:/boot/kernel # openssl sha256 ../kernel.MINIMAL/vmm.ko

SHA2-256(../kernel.MINIMAL/vmm.ko)= bf99ad827f54cde4ccd3c7f48829de14fc59895ea2b9e10b5d2baad11b5d029c
root@patchy:/boot/kernel # freebsd-version -kru ; uname -mvKU

14.0-RELEASE-p8
14.0-RELEASE-p8
14.0-RELEASE-p8
FreeBSD 14.0-RELEASE-p8 releng/14.0-n265421-5e23806790ef GENERIC amd64 1400097 1400097
root@patchy:/boot/kernel # date ; uptime

Thu Jul 11 01:57:21 BST 2024
 1:57AM  up 10 mins, 1 user, load averages: 0.02, 0.05, 0.03
root@patchy:/boot/kernel # exit

exit

Script done on Thu Jul 11 01:57:36 2024
 
It seems like Matrix. One imperfection inside the code creates Neo,the savior of humanity ?. Do you want to give a look inside the vmm.ko that should work for FreeBSD 14.1 ? I'm curious to see if you see the same pattern there.

Anyway at this point,what can we do to replicate the working pattern that's inside vmm.ko for 14.0 even on 14.1,14.2 and so on,to have the GPU passhthru for a long time ? can we identify which kind of macro or inline function it is ? can we add it to the source code of vmm.ko for the later versions of FreeBSD ? The compiler differences are on the Bileslav PC or in the compiler used by the developer that created or compiled vmm.ko ?
 
Cath O'Deray said:
Here, with an updated temporary test machine (an old MacBook Pro):

Code: 
Script started on Thu Jul 11 01:56:02 2024
root@patchy:/boot/kernel # openssl sha256 ./vmm.ko

SHA2-256(./vmm.ko)= 42b3b7d004738e8b590d147e954ab17a887f789e615741f99215042d2edbc06e
root@patchy:/boot/kernel # openssl sha256 ../kernel.GENERIC-MMCCAM/vmm.ko

SHA2-256(../kernel.GENERIC-MMCCAM/vmm.ko)= 627fdd44f3d2ee2f99d44c48c13b58e2151c8a64010f51ee485e7f83285288d7
root@patchy:/boot/kernel # openssl sha256 ../kernel.MINIMAL/vmm.ko

SHA2-256(../kernel.MINIMAL/vmm.ko)= bf99ad827f54cde4ccd3c7f48829de14fc59895ea2b9e10b5d2baad11b5d029c
root@patchy:/boot/kernel # freebsd-version -kru ; uname -mvKU

14.0-RELEASE-p8
14.0-RELEASE-p8
14.0-RELEASE-p8
FreeBSD 14.0-RELEASE-p8 releng/14.0-n265421-5e23806790ef GENERIC amd64 1400097 1400097
root@patchy:/boot/kernel # date ; uptime

Thu Jul 11 01:57:21 BST 2024
 1:57AM  up 10 mins, 1 user, load averages: 0.02, 0.05, 0.03
root@patchy:/boot/kernel # exit

exit

Script done on Thu Jul 11 01:57:36 2024
Click to expand...

can you explain this ? what do you do there ?
 
You must log in or register to reply here.
Back
Top