[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-6545":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":15,"forks30d":15,"starsTrendScore":19,"compositeScore":20,"rankGlobal":9,"rankLanguage":9,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":24,"hasPages":22,"topics":25,"createdAt":9,"pushedAt":9,"updatedAt":26,"readmeContent":27,"aiSummary":28,"trendingCount":15,"starSnapshotCount":15,"syncStatus":29,"lastSyncTime":30,"discoverSource":31},6545,"vgpu_unlock","DualCoder\u002Fvgpu_unlock","DualCoder","Unlock vGPU functionality for consumer grade GPUs.",null,"C",5269,471,112,54,0,1,8,24,5,39.02,"MIT License",false,"master",true,[],"2026-06-12 02:01:26","# vgpu\\_unlock\n\nUnlock vGPU functionality for consumer-grade Nvidia GPUs.\n\n\n## Important!\n\nThis tool is not guarenteed to work out of the box in some cases, \nso use it at your own risk.\n\n\n## Description\n\nThis tool enables the use of Geforce and Quadro GPUs with the NVIDIA vGPU\ngraphics virtualization technology. NVIDIA vGPU normally only supports a \nfew datacenter Teslas and professional Quadro GPUs by design, but not \nconsumer graphics cards through a software limitation. This vgpu_unlock tool \naims to remove this limitation on Linux based systems, thus enabling \nmost Maxwell, Pascal, Volta (untested), and Turing based GPUs to \nuse the vGPU technology. Ampere support is currently a work in progress.  \n  \nA community maintained Wiki written by Krutav Shah with a lot more information \nis [available here.](https:\u002F\u002Fdocs.google.com\u002Fdocument\u002Fd\u002F1pzrWJ9h-zANCtyqRgS7Vzla0Y8Ea2-5z2HEi4X75d2Q\u002Fedit?usp=sharing)\n\n\n## Dependencies:\n\n* This tool requires Python3 and Python3-pip; the latest version is recommended.\n* The python package \"frida\" is required. `pip3 install frida`.\n* The tool requires the NVIDIA GRID vGPU driver.\n* \"dkms\" is required as it simplifies the process of rebuilding the\n  driver alot. Install DKMS with the package manager in your OS.\n\n\n## Installation:\n\nIn the following instructions `\u003Cpath_to_vgpu_unlock>` need to be replaced with\nthe path to this repository on the target system and `\u003Cversion>` need to be\nreplaced with the version of the NVIDIA GRID vGPU driver.\n\nInstall the NVIDIA GRID vGPU driver, make sure to install it as a dkms module.\n```\n.\u002Fnvidia-installer --dkms\n```\n\nModify the line begining with `ExecStart=` in `\u002Flib\u002Fsystemd\u002Fsystem\u002Fnvidia-vgpud.service`\nand `\u002Flib\u002Fsystemd\u002Fsystem\u002Fnvidia-vgpu-mgr.service` to use `vgpu_unlock` as\nthe executable and pass the original executable as the first argument. Example:\n```\nExecStart=\u003Cpath_to_vgpu_unlock>\u002Fvgpu_unlock \u002Fusr\u002Fbin\u002Fnvidia-vgpud\n```\n\nReload the systemd daemons:\n```\nsystemctl daemon-reload\n```\n\nModify the file `\u002Fusr\u002Fsrc\u002Fnvidia-\u003Cversion>\u002Fnvidia\u002Fos-interface.c` and add the\nfollowing line after the lines begining with `#include` at the beginning of the\nfile.\n```\n#include \"\u003Cpath_to_vgpu_unlock>\u002Fvgpu_unlock_hooks.c\"\n```\n\nModify the file `\u002Fusr\u002Fsrc\u002Fnvidia-\u003Cversion>\u002Fnvidia\u002Fnvidia.Kbuild` and add the\nfollowing line at the bottom of the file.\n```\nldflags-y += -T \u003Cpath_to_vgpu_unlock>\u002Fkern.ld\n```\n\nRemove the nvidia kernel module using dkms:\n```\ndkms remove -m nvidia -v \u003Cversion> --all\n```\n\nRebuild and reinstall the nvidia kernel module using dkms:\n```\ndkms install -m nvidia -v \u003Cversion>\n```\n\nReboot.\n\n---\n**NOTE**\n\nThis script only works with graphics cards in the same generation as their \nprofessional Tesla counterparts. As a result, only Maxwell and newer \ngeneration Nvidia GPUs are supported. It is not designed to be used with\nlow end graphics card models, so not all cards are guarenteed to work \nsmoothly with vGPU. For the best experience, it is recommended to use \ngraphics cards with the same chip model as the Tesla cards. \nThe same applies to the operating system as well, as certain bleeding-edge \nLinux distributions may not work well with vGPU software.\n\n---\n\n## How it works\n\n### vGPU supported?\n\nIn order to determine if a certain GPU supports the vGPU functionality the\ndriver looks at the PCI device ID. This identifier together with the PCI vendor\nID is unique for each type of PCI device. In order to enable vGPU support we\nneed to tell the driver that the PCI device ID of the installed GPU is one of\nthe device IDs used by a vGPU capable GPU.\n\n### Userspace script: vgpu\\_unlock\n\nThe userspace services nvidia-vgpud and nvidia-vgpu-mgr uses the ioctl syscall\nto communicate with the kernel module. Specifically they read the PCI device ID\nand determines if the installed GPU is vGPU capable.\n\nThe python script vgpu\\_unlock intercepts all ioctl syscalls between the\nexecutable specified as the first argument and the kernel. The script then\nmodifies the kernel responses to indicate a PCI device ID with vGPU support\nand a vGPU capable GPU.\n\n### Kernel module hooks: vgpu\\_unlock\\_hooks.c\n\nIn order to exchange data with the GPU the kernel module maps the physical\naddress space of the PCI bus into its own virtual address space. This is done\nusing the ioremap\\* kernel functions. The kernel module then reads and writes\ndata into that mapped address space. This is done using the memcpy kernel\nfunction.\n\nBy including the vgpu\\_unlock\\_hooks.c file into the os-interface.c file we can\nuse C preprocessor macros to replace and intercept calls to the iormeap and\nmemcpy functions. Doing this allows us to maintain a view of what is mapped\nwhere and what data that is being accessed.\n\n### Kernel module linker script: kern.ld\n\nThis is a modified version of the default linker script provided by gcc. The\nscript is modified to place the .rodata section of nv-kernel.o into .data\nsection instead of .rodata, making it writable. The script also provide the\nsymbols `vgpu_unlock_nv_kern_rodata_beg` and `vgpu_unlock_nv_kern_rodata_end`\nto let us know where that section begins and ends.\n\n### How it all comes together\n\nAfter boot the nvidia-vgpud service queries the kernel for all installed GPUs\nand checks for vGPU capability. This call is intercepted by the vgpu\\_unlock\npython script and the GPU is made vGPU capable. If a vGPU capable GPU is found\nthen nvidia-vgpu creates an MDEV device and the \u002Fsys\u002Fclass\u002Fmdev\\_bus directory\nis created by the system.\n\nvGPU devices can now be created by echoing UUIDs into the `create` files in the\nmdev bus representation. This will create additional structures representing\nthe new vGPU device on the MDEV bus. These devices can then be assigned to VMs,\nand when the VM starts it will open the MDEV device. This causes nvidia-vgpu-mgr\nto start communicating with the kernel using ioctl. Again these calls are\nintercepted by the vgpu\\_unlock python script and when nvidia-vgpu-mgr asks if\nthe GPU is vGPU capable the answer is changed to yes. After that check it\nattempts to initialize the vGPU device instance.\n\nInitialization of the vGPU device is handled by the kernel module and it\nperforms its own check for vGPU capability, this one is a bit more complicated.\n\nThe kernel module maps the physical PCI address range 0xf0000000-0xf1000000 into\nits virtual address space, it then performs some magical operations which we\ndon't really know what they do. What we do know is that after these operations\nit accesses a 128 bit value at physical address 0xf0029624, which we call the\nmagic value. The kernel module also accessses a 128 bit value at physical \naddress 0xf0029634, which we call the key value.\n\nThe kernel module then has a couple of lookup tables for the magic value, one\nfor vGPU capable GPUs and one for the others. So the kernel module looks for the\nmagic value in both of these lookup tables, and if it is found that table entry\nalso contains a set of AES-128 encrypted data blocks and a HMAC-SHA256\nsignature.\n\nThe signature is then validated by using the key value mentioned earlier to\ncalculate the HMAC-SHA256 signature over the encrypted data blocks. If the\nsignature is correct, then the blocks are decrypted using AES-128 and the same\nkey.\n\nInside of the decrypted data is once again the PCI device ID.\n\nSo in order for the kernel module to accept the GPU as vGPU capable the magic\nvalue will have to be in the table of vGPU capable magic values, the key has\nto generate a valid HMAC-SHA256 signature and the AES-128 decrypted data blocks\nhas to contain a vGPU capable PCI device ID. If any of these checks fail, then\nthe error code 0x56 \"Call not supported\" is returned.\n\nIn order to make these checks pass the hooks in vgpu\\_unlock\\_hooks.c will look\nfor a ioremap call that maps the physical address range that contain the magic\nand key values, recalculate the addresses of those values into the virtual\naddress space of the kernel module, monitor memcpy operations reading at those\naddresses, and if such an operation occurs, keep a copy of the value until both\nare known, locate the lookup tables in the .rodata section of nv-kernel.o, find\nthe signature and data bocks, validate the signature, decrypt the blocks, edit\nthe PCI device ID in the decrypted data, reencrypt the blocks, regenerate the\nsignature and insert the magic, blocks and signature into the table of vGPU\ncapable magic values. And that's what they do.\n\n","vgpu_unlock项目旨在为消费级NVIDIA GPU解锁vGPU功能。通过修改NVIDIA驱动程序，该项目使得GeForce和Quadro系列的显卡能够使用原本仅限于数据中心Tesla和专业Quadro GPU的vGPU图形虚拟化技术。适用于Linux系统，支持Maxwell、Pascal、Turing架构的GPU，对Volta的支持正在测试中，而Ampere架构的支持还在开发阶段。此工具需要Python3环境及Frida库，并且必须安装NVIDIA GRID vGPU驱动。它特别适合那些希望在个人或小型企业环境中利用已有硬件资源进行GPU虚拟化的用户。需要注意的是，由于涉及底层驱动修改，使用时需谨慎评估风险。",2,"2026-06-11 03:07:32","top_language"]