From: Jason Chen CJ <jason.cj.chen@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: <kvm@vger.kernel.org>
Subject: Re: [RFC PATCH part-1 0/5] pKVM on Intel Platform Introduction
Date: Thu, 16 Mar 2023 08:50:09 +0000 [thread overview]
Message-ID: <ZBLYQYXdGsYfY2IN@jiechen-ubuntu-dev> (raw)
In-Reply-To: <ZBCC3qEPHGWnx2JO@google.com>
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
next prev parent reply other threads:[~2023-03-16 0:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-12 18:00 [RFC PATCH part-1 0/5] pKVM on Intel Platform Introduction Jason Chen CJ
2023-03-12 18:00 ` [RFC PATCH part-1 1/5] pkvm: arm64: Move nvhe/spinlock.h to include/asm dir Jason Chen CJ
2023-03-12 18:00 ` [RFC PATCH part-1 2/5] pkvm: arm64: Make page allocator arch agnostic Jason Chen CJ
2023-03-12 18:00 ` [RFC PATCH part-1 3/5] pkvm: arm64: Move page allocator to virt/kvm/pkvm Jason Chen CJ
2023-03-12 18:00 ` [RFC PATCH part-1 4/5] pkvm: arm64: Make memory reservation arch agnostic Jason Chen CJ
2023-03-12 18:00 ` [RFC PATCH part-1 5/5] pkvm: arm64: Move general part of memory reservation to virt/kvm/pkvm Jason Chen CJ
2023-03-13 16:33 ` [RFC PATCH part-1 0/5] pKVM on Intel Platform Introduction Sean Christopherson
2023-03-14 16:17 ` Jason Chen CJ
2023-03-14 14:21 ` Sean Christopherson
2023-03-16 8:50 ` Jason Chen CJ [this message]
2023-03-24 10:30 ` Keir Fraser
2023-06-07 14:26 ` Mickaël Salaün
2023-06-08 21:06 ` Dmytro Maluka
[not found] ` <d0900265-6ae6-2430-8185-4f9d153ec105@intel.com>
2023-06-09 8:08 ` Dmytro Maluka
2023-06-09 16:57 ` Trilok Soni
2023-06-09 18:44 ` Dmytro Maluka
2023-06-10 8:56 ` Dmytro Maluka
2023-06-13 17:45 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZBLYQYXdGsYfY2IN@jiechen-ubuntu-dev \
--to=jason.cj.chen@intel.com \
--cc=kvm@vger.kernel.org \
--cc=seanjc@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox