On Fri Sep 13, 2024 at 7:19 PM UTC, Sean Christopherson wrote:
> 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?
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@xxxxxxxxx
