文章摘要
TinyKVM最初专注于纯计算用途，现已扩展支持运行未修改的可执行程序，如Deno、Python WSGI等运行时。作者采用了非传统的系统调用模拟方法，尽量减少系统调用数量。项目已开源，并推荐尝试KVM server作为TinyKVM的CLI工具。
文章总结
TinyKVM项目进展更新
项目背景与功能扩展
TinyKVM于今年2月开源后，开发者突破了最初纯计算用途的设计局限，新增了对未修改可执行程序的支持。现在可以运行Deno、Python WSGI和Lune等运行时环境。特别致谢Laurence Rowe开发的KVM server，它已成为TinyKVM服务器的准标准CLI工具。
系统调用模拟实现
项目采用非传统方式实现了最小化系统调用模拟： - 仅支持50个核心系统调用（对比gVisor的200个） - 严格限制共享内核访问，仅允许必要操作如： - 设置/获取非阻塞模式（FIONBIO） - 读取可用字节数（FIONREAD） 建议生产环境配合Jailer使用，形成"Jailer + TinyKVM + Deno + 请求级隔离"的安全架构。
请求级隔离技术突破
混合重置模式：
- 主模式：快速重置被修改内存页，保留页表和TLB（速度最快但内存占用递增）
- 次模式：当内存超限时完全重置VM（处理大内存请求）
性能表现：
- 在Deno页面渲染测试中，TinyKVM的p90+延迟低于原生环境
- 每次请求重置完整VM的状态下，仍能接近原生性能
创新RPC机制
开发了独特的远程过程调用方案： - 直接函数跳转：通过陷阱机制切换线程指针(FSBASE)，实现跨程序直接调用 - 两种安全模式： 1. 持久化VM以"高权限"方式接管调用者地址空间 2. 按需映射远程VM函数，执行后立即解除映射 - 性能指标：当前调用延迟约2微秒，未来可通过INVPCID指令优化
VM快照功能
新实现的快照特性： - 单文件存储所有物理内存和VM状态（含用户自定义数据） - Deno示例：192MiB内存占用可压缩为135MiB快照文件 - 启动时间：页面缓存命中时0.7ms，冷启动约20ms - 正在开发智能预加载技术，仅载入必要内存页以优化启动速度
项目持续探索更快的冷启动方案，通过精确控制内存页加载来超越现有解决方案。目前这些进展展示了TinyKVM在轻量级虚拟化领域的创新潜力。
（注：原文中的图片引用、个人订阅推广及部分技术细节讨论已根据中文阅读习惯精简）
评论总结
以下是评论内容的总结：
对TinyKVM功能的探讨与期待
- 用户3eb7988a1663询问是否能用TinyKVM运行GUI程序（如Firefox）并限制其权限，认为其沙箱性能可能比其他解决方案更安全高效。 引用："Is there any way that TinyKVM + KVM Server could ever be made to work with a GUI program?" 引用："I am wondering if I could default wrap every command on my terminal to run inside a TinyKVM"
- laurencerowe期待TinyKVM的请求隔离和快照功能能提升服务器端JS运行的效率。 引用："the combination of per-request isolation and the new snapshot functionality...will be a big step forward"
对项目名称的混淆
- 多位用户（acjohnson55、sterlinm、dinobones）提到将TinyKVM与KVM切换器、PiKVM或TinyPilot等硬件项目混淆。 引用："Does the 'KVM' part have any connection to a KVM switch?" 引用："I was confusing it with TinyPilot, a hardware KVM"
对项目的积极评价
- RobLach和deivid表达了对项目的赞赏，deivid还分享了自己在快速启动KVM方面的经验。 引用："This is great in how simple it seems." 引用："This is amazing! I am also a little bit obsessed with fast-booting kvm"
对项目信息的询问
- mattbee提供了项目作者的介绍链接，skybrian和nl询问项目的概述及与Amazon Firecracker的比较。 引用："here’s an introduction from the author" 引用："How does this compare to Amazon’s Firecracker VM?"
总结：评论主要围绕TinyKVM的功能潜力、名称混淆、积极评价和信息需求展开，展现了用户对其技术实现和应用场景的兴趣与期待。