On Fri, May 10, 2024 at 10:07:00AM +0000, Nicolas Saenz Julienne wrote: > On Tue May 7, 2024 at 4:16 PM UTC, Sean Christopherson wrote: > > > If yes, that would indeed require a *lot* of work for something we're not > > > sure will be accepted later on. > > > > Yes and no. The AWS folks are pursuing VSM support in KVM+QEMU, and SVSM > > support > > is trending toward the paired VM+vCPU model. IMO, it's entirely feasible to > > design KVM support such that much of the development load can be shared > > between > > the projects. And having 2+ use cases for a feature (set) makes it _much_ > > more > > likely that the feature(s) will be accepted. > > Since Sean mentioned our VSM efforts, a small update. We were able to > validate the concept of one KVM VM per VTL as discussed in LPC. Right > now only for single CPU guests, but are in the late stages of bringing > up MP support. The resulting KVM code is small, and most will be > uncontroversial (I hope). If other obligations allow it, we plan on > having something suitable for review in the coming months.
Looks good! > > Our implementation aims to implement all the VSM spec necessary to run > with Microsoft Credential Guard. But note that some aspects necessary > for HVCI are not covered, especially the ones that depend on MBEC > support, or some categories of secure intercepts. We already implemented support for MBEC, so that should not be an issue. We just need to find the best interface to configure it. > > Development happens > https://github.com/vianpl/{linux,qemu,kvm-unit-tests} and the vsm-next > branch, but I'd advice against looking into it until we add some order > to the rework. Regardless, feel free to get in touch. Thanks for the update. Could we schedule a PUCK meeting to synchronize and help each other? What about June 12?
