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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 14, 2023 at 07:21:18AM -0700, Sean Christopherson wrote:
> On Tue, Mar 14, 2023, Jason Chen CJ wrote:
> > 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 
> 
> Who is "we"?  Unless Intel is making a rather large pivot, I doubt Intel is the
> end customer of pKVM-on-x86.  If you aren't at liberty to say due NDA/confidentiality,
> then please work with whoever you need to in order to get permission to fully
> disclose the use case.  Because realistically, without knowing exactly what is
> in scope and why, this is going nowhere.  
> 
> > to run protected VM with general OS and may with pass-thru secure devices support.
> 
> Why?  What is the actual use case?

Sorry for the confusion, I will try my best to give a general
description of the exact use case.

The use case is for client platform with requirement for confidential
computing:

 - host VM is still working as primary OS (act like native), it will
   launch its required normal VM (e.g., a Linux or android OS)
 - protected VM (e.g,, a Linux OS) is working as a TEE, it launched by
   host VM but finally isolated to host VM and other launched VMs, and
   it may run with pass-thru secure device (e.g., finger printer, secure
   camera etc.)

The general OS support for protected VM is ideal case, I suppose that
most likely user can be convinced to restrict it as a limit one
like 64-bit OS.

> 
> > 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?
> 
> Throw away TDX and let KVM run its own code in SEAM.

May I ask what do you mean "KVM run its own code in SEAM"? The target
platform to run pKVM on x86 is not expected to support TDX. Do you mean
we should keep same interface as SEAM?


-- 

Thanks
Jason CJ Chen



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux