Re: [RFC PATCH part-1 0/5] pKVM on Intel Platform Introduction

[Jason Chen CJ <jason.cj.chen@intel.com>]

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