这算啥，还有逗号作为小数点，分号作为表格分隔符的 bug. 牵扯到 locale 的问题，需要花很多精力维护，没有国际化的业务，不考虑这些“特殊”用户才是上策。

@mxT52CRuqR6o5 可以参考这篇文章
https://3os.org/infrastructure/proxmox/gpu-passthrough/igpu-passthrough-to-vm/
我 host 内核参数只保留了 quiet intel_iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1
显卡屏蔽只屏蔽了 Intel 驱动 i915 和 nvidia 的驱动(我上面还接了一张 n 卡)

12 代的区别就是 VM 的内核, 驱动和相关依赖得非常新, 稍微旧一点的内核比如 5.19.10 在我这 intel_gpu_top 都会报错
Failed to detect engines! (No such file or directory)

最新的 6.0.0 内核什么参数都不需要加直接就支持 12 代核显
以前的内核还需要加 i915.force_probe=4690
在直通了核显的 VM 上 dmesg | grep i915
内容应该和下面的差不多
[ 5.060294] i915 0000:01:00.0: [drm] VT-d active for gfx access
[ 5.060351] i915 0000:01:00.0: [drm] Using Transparent Hugepages
[ 5.076393] i915 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xbbcf
[ 5.076673] i915 0000:01:00.0: [drm] Failed to find VBIOS tables (VBT)
[ 5.077164] i915 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none
[ 5.093245] i915 0000:01:00.0: firmware: direct-loading firmware i915/adls_dmc_ver2_01.bin
[ 5.093696] i915 0000:01:00.0: [drm] Finished loading DMC firmware i915/adls_dmc_ver2_01.bin (v2.1)
[ 6.619475] i915 0000:01:00.0: [drm] failed to retrieve link info, disabling eDP
[ 6.628504] i915 0000:01:00.0: firmware: direct-loading firmware i915/tgl_guc_70.1.1.bin
[ 6.629399] i915 0000:01:00.0: firmware: direct-loading firmware i915/tgl_huc_7.9.3.bin
[ 6.725923] i915 0000:01:00.0: [drm] GuC firmware i915/tgl_guc_70.1.1.bin version 70.1
[ 6.725931] i915 0000:01:00.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9
[ 6.734941] i915 0000:01:00.0: [drm] HuC authenticated
[ 6.734945] i915 0000:01:00.0: [drm] GuC submission disabled
[ 6.734946] i915 0000:01:00.0: [drm] GuC SLPC disabled
[ 6.736822] [drm] Initialized i915 1.6.0 20201103 for 0000:01:00.0 on minor 1
[ 6.737161] i915 0000:01:00.0: [drm] Cannot find any crtc or sizes
[ 6.737255] i915 0000:01:00.0: [drm] Cannot find any crtc or sizes

intel_gpu_top 应该可以正常启动:
intel-gpu-top: Intel Alderlake_s (Gen12) @ /dev/dri/card1 - 0/ 0 MHz; 100% RC6; 0 irqs/s

然后此时, 你就可以调用核显, 比如硬解视频, 看看实际的核显占用情况和稳定性了.

我 VM 的内核升级到 6.0.0 内核以后硬解就没崩溃过了(连续测试了 3 天, 硬解了超过 20 小时不同编码码率的视频无崩溃, qsv 的性能还是很让人满意的), VM 系统为 Debian sid, 内核版本 6.0.0-2-amd64. 仅供参考.
如果你和我一样在 vm 里跑的是 docker 容器硬解, 容器镜像的 intel compute runtime 和 ffmpeg 版本也非常重要, 一定要选择驱动和相关依赖库都比较新的容器!! 否则很可能就不能正常调用 12 代核显进行 qsv 硬解, 只能退而求其次用 vaapi 硬解.

宿主机 proxmox 的内核还是 5.19.7-2-pve, 它只需要负责把核显交给 VM, 并不需要最新的 intel compute runtime 之类的, 所以内核不用太新问题也不大.

@mxT52CRuqR6o5 它用的 arch 自己修改的 i915 驱动放在 AUR 上. 我的 debian sid 看来要用还得改.
而且看回帖, 目前 windows vm 上能打驱动但是无法使用.

单个直通其实在最新的内核上已经挺稳定了, 但是 sriov 多个直通有人说做到了, 却暂时还没有稳定性的报告(因为之前旧驱动就算单个直通成功, 运行大概 2 个小时左右就会崩溃 GPU HANG, 实际是不可用的).

LTS 和 upstream 差了 N 个版本吧, 再说安全问题这种东西和内核新老根本无关.

而且有安全问题的时候 patch 基本上都会 backport 到旧内核上的.

linux 的内核新旧只是对新硬件的支持有区别, 还有一些核心依赖库的版本区别.

@f165af34d4830eeb 我试过了，需要 6.0 以上的内核并集成了最新的 intel compute runtime （这个需要最新的 libc6 等依赖，很多稳定版的 linux 发行版都版本过低） 和 最新的 i915 驱动才能比较完整的支持大小核调度和新核显。
目前就算是最新的 debian 和 ubuntu 稳定版都不行，得用 sid 或者 unstable 。

@chenjiangui998 移动端和桌面端不一样, 12 代移动端还需要 guc huc 那些电源管理驱动, 不然 lowpower encode decode 那些功能启用的时候会出错.
至于稳定性, 我手上没有, 没法测试.

pve 的 host 插个 pcie 设备, 网卡序号不会自动更新导致 host 断网的问题到现在还不修, 就一个脚本的事情...

webui 的强制重启根本不是 force kill 的问题也是不修.

还是自己撸脚本靠谱

@f165af34d4830eeb windows 看评论情况好一些, 要根据自己的硬件配置找一个不崩溃的特定版本驱动, 因为最新的崩, 旧版本也崩...
只是要关掉 windows 更新避免自动更新到崩溃的版本.

最治标治本的方法是挂载字体到容器下的 /usr/share/fonts/里
例如:
下载 Sarasa Gothic (更纱黑体)
https://github.com/be5invis/Sarasa-Gothic/releases
把你想要的简繁字体放到一个文件夹里
例如:
/home/docker/data/jellyfin/fonts/sarasa
sarasa-gothic-sc-bolditalic.ttf sarasa-gothic-sc-regular.ttf sarasa-gothic-tc-italic.ttf
sarasa-gothic-sc-bold.ttf sarasa-gothic-sc-semibolditalic.ttf sarasa-gothic-tc-lightitalic.ttf
sarasa-gothic-sc-extralightitalic.ttf sarasa-gothic-sc-semibold.ttf sarasa-gothic-tc-light.ttf
sarasa-gothic-sc-extralight.ttf sarasa-gothic-tc-bolditalic.ttf sarasa-gothic-tc-regular.ttf
sarasa-gothic-sc-italic.ttf sarasa-gothic-tc-bold.ttf sarasa-gothic-tc-semibolditalic.ttf
sarasa-gothic-sc-lightitalic.ttf sarasa-gothic-tc-extralightitalic.ttf sarasa-gothic-tc-semibold.ttf
把这个文件夹挂载到容器的 /usr/share/fonts/ 底下
docker-compose:
- /home/docker/data/jellyfin/fonts/sarasa:/usr/share/fonts/sarasa

这样视频转码的时候, 出现找不到字体的情况, 会自动去读取这个字体
[Parsed_subtitles_3 @ 0x56524347a040] Using font provider fontconfig
[Parsed_subtitles_3 @ 0x56524347a040] fontselect: (方正中雅宋_GBK, 400, 0) -> /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf, 0, DejaVuSans
[Parsed_subtitles_3 @ 0x56524347a040] Glyph 0x672C not found, selecting one more font for (方正中雅宋_GBK, 400, 0)
[Parsed_subtitles_3 @ 0x56524347a040] fontselect: (方正中雅宋_GBK, 400, 0) -> /usr/share/fonts/sarasa/sarasa-gothic-sc-regular.ttf, 0, Sarasa-Gothic-SC-Regular

@pusheax 如果他的文件系统用的是 ZFS 这种吃内存的，内存出错带来的后果会更严重，ECC 相当有必要。
他之前还吐槽急着想把内核 rust 化的开发者 rust 也有不稳定的问题。做内核的就是稳定性压倒一切。

@Runm 主要现在甜品显卡新品都缺胳膊少腿还贵的，可能买个旧显卡比如 1650 之类的拿来直通 windows 就 ok 了

本人就是在国内 985 ，211 修完本科，再去法国修完 L3 和 M2 的计算机专业的，法国同学虽然编程水平不尽相同，除了那种摸鱼的学生，数学平均基本没有很差的，概率统计高数平均分都能考个 13 左右（满分 20, 考试题目一点都不比国内简单）。
有的营销号天天宣扬外国数学水平差，还真的有人信，真出去了怕不是直接挂科留级。

@echo1937 就是 vm 不会独占显卡，一个显卡多个 vm 同时使用. bios 里给显卡多分配一些显存可以增加服务稳定性。
load 过大崩了可以用 cron 脚本重启 vm 或者 watchdog 自动重启解决。
个人觉得很实用的特性，因为不仅仅是硬解加速需要显卡，我的一些其它应用（不想放在影音服务器 vm 上）也需要，多插一张显卡的话费电不说还得额外花钱买。

能跳过 recaptcha, ncaptcha, 拼图之类验证吗？

宿主机是直接把分配的内存全额划给对应的虚拟机，虚拟机显示的是虚拟内存的占用情况，空闲的内存不能被虚拟机外部其它虚拟机使用

@MajestySolor 很简单，因为以前没有实用的搜索引擎

web3 能解决大厂数据垄断吗？ 不能，最多只是换一批大厂垄断。
web3 能解决版权所有权问题吗？不能，因为没有法律支撑，你用 nft 声明所有权人家想盗用照样盗用，最终维权还是得靠所在国家的法律和执行机关。

@knightjun 你想多了, 它的详细 traceback log 都是在后台记录的, 给你用户看也看不懂, 所以干脆就不显示, 自动或者手动 report 的时候就会回传详细错误.

如果有 AD, 就用组策略 (在用户属性-Account 那个选项卡里面有个 Log On To)
没用 AD 的话, 只能用 ACL 通过不同机器分配不同账号间接实现了

而且无论用 netBIOS 还是 DNS 还是 MAC address 都是可以被欺骗的, 所以并不是什么很好的安全策略.