From: "Yao, Jiewen" <jiewen.yao@intel.com>
To: Joerg Roedel <jroedel@suse.com>
Cc: "linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
James Bottomley <jejb@linux.ibm.com>,
Claudio Siqueira de Carvalho <cclaudio@ibm.com>,
"Lange, Jon" <jlange@microsoft.com>,
"Dong, Eddie" <eddie.dong@intel.com>,
"Johnson, Simon P" <simon.p.johnson@intel.com>,
"Reshetova, Elena" <elena.reshetova@intel.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>
Subject: RE: question on vTPM interface in coconut-svsm
Date: Mon, 8 Apr 2024 15:05:11 +0000 [thread overview]
Message-ID: <MW4PR11MB5872AEC8837A86F7BCB1AD918C002@MW4PR11MB5872.namprd11.prod.outlook.com> (raw)
In-Reply-To: <C8994858-F06E-44E8-BA57-B47BFB7411B6@suse.com>
Thank you very much Joerg. That explains a lot.
Yes, I am in the internal process of posting CRB based vTPM solution in coconut-SVSM. Once the internal process is complete, we will submit the CRB patch.
Thank you
Yao, Jiewen
> -----Original Message-----
> From: Joerg Roedel <jroedel@suse.com>
> Sent: Monday, April 8, 2024 4:51 PM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: linux-coco@lists.linux.dev; James Bottomley <jejb@linux.ibm.com>; Claudio
> Siqueira de Carvalho <cclaudio@ibm.com>; Lange, Jon <jlange@microsoft.com>;
> Dong, Eddie <eddie.dong@intel.com>; Johnson, Simon P
> <simon.p.johnson@intel.com>; Reshetova, Elena <elena.reshetova@intel.com>;
> Nakajima, Jun <jun.nakajima@intel.com>
> Subject: Re: question on vTPM interface in coconut-svsm
>
> Hi Jiewen,
>
> First of all: I it really great that Intel plans to use and contribute to COCONUT-
> SVSM! For your questions, let me add some general statements here about how
> COCONUT plans to handle device interfaces in the future.
>
> > Am 28.03.2024 um 07:29 schrieb Yao, Jiewen <jiewen.yao@intel.com>:
> >
> > Questions:
> > With this POC, it seems TCG CRB interface [7] is a feasible option for vTPM in
> coconut-svsm. We are NOT clear what is the motivation to have a new vTPM
> protocol [4].
> > Would you please educate us on that? Why not reuse TCG CRB interface [7], but
> introduce a new one [4]?
>
> The current vTPM code in COCONUT-SVSM implements an SVSM specific
> communication mechanism between the guest OS and the SVSM. The main
> reason behind this is that the implementation for AMD SEV-SNP targets an
> operation mode for running enlightened OSes. That means that the OS is aware of
> running in a CVM and also on-top of an SVSM. The OS still handles VC exceptions
> (equivalent of VE on TDX) itself, which makes it harder to emulate an MMIO-
> based device interface in the SVSM. Since the OS is already aware of the SVSM
> and because of the difficulties of implementing a CRB interface in this mode, the
> SVSM offers a communication protocol to the OS for using the TPM emulation.
>
> In the future the SVSM will also support the paravisor mode, where it handles
> VC/VE exceptions on behalf of the guest OS. In this mode the SVSM will emulate
> MMIO and it makes more sense to offer a TPM interface via CRB because the
> guest OS might not be aware of running in a CVM and/or on-top of a paravisor.
>
> So if Intel wants to support paravisor mode for TDX first and add enlightened OS
> support later, it is totally fine to implement a CRB interface in front of the existing
> TPM implementation in addition to the existing SVSM protocol interface.
>
> In general this is true for all device emulations the SVSM will provide in the future.
> In enlightened OS mode it is easier and more performant to define SVSM-specific
> protocols and in paravisor mode the SVSM can implement the interface of the real
> hardware device it is emulating.
>
> Hope that clarifies a few things, let me know if you have further questions.
>
> Regards,
>
> Jörg
prev parent reply other threads:[~2024-04-08 15:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <MW4PR11MB5872CE9BEF8361203F72EDFD8C3B2@MW4PR11MB5872.namprd11.prod.outlook.com>
2024-03-28 6:29 ` question on vTPM interface in coconut-svsm Yao, Jiewen
2024-03-28 8:11 ` Reshetova, Elena
2024-03-28 9:11 ` Joerg Roedel
2024-03-28 12:03 ` James Bottomley
2024-03-28 12:22 ` Jeremi Piotrowski
2024-03-28 12:33 ` James Bottomley
2024-03-28 13:41 ` Jeremi Piotrowski
2024-03-28 13:54 ` James Bottomley
2024-03-28 14:09 ` Jeremi Piotrowski
2024-04-08 8:50 ` Joerg Roedel
2024-04-08 15:05 ` Yao, Jiewen [this message]
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=MW4PR11MB5872AEC8837A86F7BCB1AD918C002@MW4PR11MB5872.namprd11.prod.outlook.com \
--to=jiewen.yao@intel.com \
--cc=cclaudio@ibm.com \
--cc=eddie.dong@intel.com \
--cc=elena.reshetova@intel.com \
--cc=jejb@linux.ibm.com \
--cc=jlange@microsoft.com \
--cc=jroedel@suse.com \
--cc=jun.nakajima@intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=simon.p.johnson@intel.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).