On Tue, 2024-08-06 at 08:21 +0000, Reshetova, Elena wrote:

quoted

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.

You want the SVSM vTPM service for its tight binding to the guest VM, I
believe ... and you want to add a CRB emulation to the SVSM that
currently doesn't exist.

 I assume you've done the same for other SVSM provided services like

quoted

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?

OK, I looked but couldn't find it: how do you current add and remove
memory from the SVSM if you don't communicate with it?

 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.

Even in your model the SVSM performs services on behalf of the guest. I
think you mostly use traps and emulation instead of communication along
enlightened interfaces to get the SVSM to perform the services but one
of the historical lessons of virtualization has been that paravirt
enlightenments are useful in places (most particularly drivers).

Regards,

James

 Since the high level operations will be pretty

quoted

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. 

quoted

Regards,

James