On Sun, Jun 09, 2024, Nicolas Saenz Julienne wrote: > This series introduces core KVM functionality necessary to emulate Hyper-V's > Virtual Secure Mode in a Virtual Machine Monitor (VMM). ... > As discussed at LPC2023 and in our previous RFC [2], we decided to model each > VTL as a distinct KVM VM. With this approach, and the RWX memory attributes > introduced in this series, we have been able to implement VTL memory > protections in a non-intrusive way, using generic KVM APIs. Additionally, each > CPU's VTL is modeled as a distinct KVM vCPU, owned by the KVM VM tracking that > VTL's state. VTL awareness is fully removed from KVM, and the responsibility > for VTL-aware hypercalls, VTL scheduling, and state transfer is delegated to > userspace. > > Series overview: > - 1-8: Introduce a number of Hyper-V hyper-calls, all of which are VTL-aware and > expected to be handled in userspace. Additionally an new VTL-specifc MP > state is introduced. > - 9-10: Pass the instruction length as part of the userspace fault exit data > in order to simplify VSM's secure intercept generation. > - 11-17: Introduce RWX memory attributes as well as extend userspace faults. > - 18: Introduces the main VSM CPUID bit which gates all VTL configuration and > runtime hypercalls. Aside from the RWX attributes, which to no one's surprise will need a lot of work to get them performant and functional, are there any "big" TODO items that you see in KVM? If this series is more or less code complete, IMO modeling VTLs as distinct VM structures is a clear win. Except for the "idle VTL" stuff, which I think we can simplify, this series is quite boring, and I mean that in the best possible way :-)
