On Thu, Nov 30, 2023 at 07:08:00AM +0000, Reshetova, Elena wrote:
... 3. Normal TDX 1.0 guest that is unaware that it runs in partitioned environment 4. and so on
There's a reason I call it a virt zoo.
I don’t know if AMD architecture would support all this spectrum of the guests through.
I hear threats...
Instead we should have a flexible way for the L2 guest to discover the virt environment it runs in (as modelled by L1 VMM) and the baseline should not to assume it is a TDX or SEV guest, but assume this is some special virt guest (or legacy guest, whatever approach is cleaner) and expose additional interfaces to it.
You can do flexible all you want but all that guest zoo is using the kernel. The same code base which boots on gazillion incarnations of real hardware. And we have trouble keeping that code base clean already.
Now, all those weird guests come along, they're more or less "compatible" but not fully. So they have to do an exception here, disable some feature there which they don't want/support/cannot/bla. Or they use a paravisor which does *some* of the work for them so that needs to be accomodated too.
And so they start sprinkling around all those "differences" around the kernel. And turn it into an unmaintainable mess. We've been here before - last time it was called "if (XEN)"... and we're already getting there again only with two L1 encrypted guests technologies. I'm currently working on trimming down some of the SEV mess we've already added...
So - and I've said this a bunch of times already - whatever guest type it is, its interaction with the main kernel better be properly designed and abstracted away so that it doesn't turn into a mess.
Thx.