> On Wed, Nov 22, 2023 at 06:19:20PM +0100, Jeremi Piotrowski wrote: > > Which approach do you prefer? > > I'm trying to figure out from the whole thread, what this guest is. > > * A HyperV second-level guest > > * of type TDX > > * Needs to defer cc_mask and page visibility bla... > > * needs to disable TDX module calls > > * stub out tdx_accept_memory > > Anything else? > Actually I want to challenge the whole notion that a TDX partitioning L2 guest is a TDX guest. By the definition of the TDX partitioning spec, L2 guest can be anything and L1 VMM can emulate any environment for its L2 guests, including running a fully unmodified TDX 1.0 guest (and virtualizing TDG calls for it and whatever else is needed). So we are really talking about a big spectrum of possible L2 guests: 1. Normal legacy guest without *any* TDX knowledge 2. Normal legacy guest with some awareness of TDX partitioning (note, not TDX 1.0 aware!) (being able to do tdvmcalls to L0, being able to use shared memory, being able to use tdx partitioning specific paravirt interface to L1 if defined, etc) ... 3. Normal TDX 1.0 guest that is unaware that it runs in partitioned environment 4. and so on I don’t know if AMD architecture would support all this spectrum of the guests through. If it does, then we can discuss this vendor agnostic, which is much better. Given that the many possible combinations of the L2 guests (and as Kai rightfully pointed out, each option will be further broken down by what exactly interface L1 VMM decides to expose to the guest), I think we cannot hardcode any logic about what this partitioned guest is in the guest itself. 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. Best Regards, Elena.
