On Mon, 2024-08-05 at 09:55 +0000, Reshetova, Elena wrote:

quoted

quoted

On Fri, 2024-08-02 at 18:54 -0700, Dionna Amalie Glaze wrote:

[...]

quoted

quoted

That brings me to a curious point: is the Intel TDX SVSM going to
follow the SVSM protocol interface?  because if it is, it will
naturally inherit the enlightened interface (the code will be
present in the kernel, so it only needs activating).  However, if
the Intel SVSM were going to ignore the SVSM protocol spec then it
would have to reinvent everything and the CRB interface might make
more sense.

I cannot speak on behalf of the Intel TDX *SVSM* implementation, but
for the Linux guest kernel there is no intention at the moment to
support smth like SVSM protocol interface. We have made an evaluation
on this during the spring. There are no usecases currently that
require such new protocol introduction on Intel TDX and it does bring
additional code complexity, etc.
If anyone believes otherwise, please let me know.

If you reinvent the vTPM communication interface, I can see you are
able to get away without that SVSM communication component.

The goal is exactly the opposite, i.e. don't reinvent anything, but
try to stick with exiting ways on how we have been doing things so far in
Linux. In this light SVSM is an invention to do things.


 I assume

you've done the same for other SVSM provided services like
deposit/remove memory and vcpu create/delete, but what about migration
when it comes along? 

Could you please give an example of where let's say we are not ok with
existing Linux ways of depositing/removing memory? Why do we need
to create a new protocol like SVSM from guest kernel for doing this?
It can be done if there is a valid usecase of course. All I am saying is that
we haven’t found any yet.

 Since the high level operations will be pretty

much identical on AMD and Intel it would be very annoying to have to do
it in completely different ways (with presumably different tools).

Migration is a separate story, which i dont think has any conclusion yet
or agreement in the community. We (Intel TDX) have a way to migrate
the guest without the guest assistance, so we dont have a strict requirement
to migrate out of SVSM. It remains to be seen what method(s) is to be 
selected at the end. And if svsm-based migration method is going to be
supported for intel tdx, then it needs a separate analysis to determine
what is the actual required communication between the L2 guest and
SVSM in our case and whenever the usage of the SVSM-style protocol
is necessary.  

Imo migration is one of the topics that would be great to discuss at LPC.

Best Regards,
Elena. 

Regards,

James