On Fri Sep 13, 2024 at 7:19 PM UTC, Sean Christopherson wrote:

On Sun, Jun 09, 2024, Nicolas Saenz Julienne wrote:

quoted

This series introduces core KVM functionality necessary to emulate Hyper-V's
Virtual Secure Mode in a Virtual Machine Monitor (VMM).

...

quoted

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?

Aside from VTLs and VTL switching, there is bunch of KVM features we
still need to be fully compliant with the VSM spec:
- KVM_TRANSLATE2, which Nikolas Wipper posted a week ago [1].
  Technically we can do this in user-space, but it's way simpler to
  re-use KVM's page-walker.

- Hv's TlbFlushInhibit, it allows VTL1 to block VTL0 vCPUs from issuing
  TLB Flushes, and blocks them until uninhibited. Note this only applies
  to para-virtualized TLB flushes:
  HvFlushVirtualAddress{Space,SpaceEx,List,ListEx}, so it's 100% Hyper-V
  specific.

- CPU register pinning/intecepting, we plan on reusing what HEKI
  proposed some time ago, and expose it through an IOCTL using ONE_REG
  to represent registers.

- MBEC aware memory attributes, we don't plan on enabling support for
  these with the first RWX memattrs submission. We'll do it as a follow
  up, especially as not every Windows VBS feature requires it
  (Credential Guard doesn't need it, HVCI does).

If this series is more or less code complete, IMO modeling VTLs as distinct VM
structures is a clear win.

I agree.

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 :-)

:)

Thanks,
Nicolas

[1] https://lore.kernel.org/kvm/20240910152207.38974-1-nikwip@amazon.de (local)