On Mon, Mar 13, 2023 at 09:33:41AM -0700, Sean Christopherson wrote: > On Mon, Mar 13, 2023, Jason Chen CJ wrote: > > There are similar use cases on x86 platforms requesting protected > > environment which is isolated from host OS for confidential computing. > > What exactly are those use cases? The more details you can provide, the better. > E.g. restricting the isolated VMs to 64-bit mode a la TDX would likely simplify > the pKVM implementation. Thanks Sean for your comments, I am very appreciated! We are expected to run protected VM with general OS and may with pass-thru secure devices support. Yes, restricting the isolated(protected) VMs to 64-bit mode could simplify the pKVM implementation, I think it should be considered. Especially it could benefit vmcs isolation for protected VM - it echoes to your comments on VMX emulation. But we have a pain point to support normal VM. You know, TDX SEAM only take care protected VM, it has dedicated secure EPT, TDCS etc. for a protected VM; while for normal VM, it still go to the old KVM logic as legacy EPT, VMCS kind of thing are still there. For pKVM, we must rely on EPT, VMCS, IOMMU to do the isolation, so move them to the hypervisor, and KVM-high need to manage them through pKVM for both normal & protected VM: - for EPT, technically, both paravirtualize & emulation method works, we choose to use EPT emulation only because we do not want to change KVM x86 MMU code. I am open to switch to paravirtualize method especially after TDX patches got merged - we can leverage from it but with more consideration to support normal VM. - for VMCS, it's more tricky, as the best solution is that normal VM run with emulated VMX to see full VMCS features, while protected VM run with paravirtualized VMX to limit supported features (which simplify the implementation in pKVM for VMCS isolation & management). - for IOMMU, it has similar situation as EPT. > > > HW solutions e.g. TDX [5] also exist to support above use cases. But > > they are available only on very new platforms. Hence having a software > > solution on massive existing platforms is also plausible. > > TDX is a software solution, not a hardware solution. TDX relies on hardware features > that are only present in bleeding edge CPUs, e.g. SEAM, but TDX itself is software. Agree. > > I bring that up because this RFC, especially since it's being posted by folks > from Intel, raises the question: why not utilize SEAM to implement pKVM for x86? Some feedback in above, I suppose SEAM can be leveraged to support protected VM, but with some further questions: - how to support normal VM? if we have tradeoff to limit normal VM's feature (same as protected VM), then things may become easier - but I don't think it's friendly to end users. If we want to run normal VM as what KVM can run now, we need to add extra code in SEAM. - do we want to follow same interface? My feeling to TDX interface like SEAMCALL for SEPT PAGE.ADD/AUG SEPT.ADD etc are complicated, for pKVM, we can actually use simpler & straight-forward hypercall like host_donate_guest, host_donate_hyp, host_share_guest.... And further more in protected VM (which is TD guest in TDX), PAGE.ACCEPT may not need for pKVM, and page sharing (based on SHARED_BIT) may also have different implementation for pKVM. - do we want to leverage the page ownership mechanism like PAMT? I have to say pKVM also aready have one page state management mechanism can easily be used. May I know your suggestion of "utilize SEAM" is to follow TDX SPEC then work out a SW-TDX solution, or just do some leverage from SEAM code? -- Thanks Jason CJ Chen
