On Sat, Dec 30, 2023 at 6:26 PM Michael Roth <michael.roth@xxxxxxx> wrote: > > From: Brijesh Singh <brijesh.singh@xxxxxxx> > > The KVM_SNP_INIT command is used by the hypervisor to initialize the > SEV-SNP platform context. In a typical workflow, this command should be > the first command issued. When creating SEV-SNP guest, the VMM must use > this command instead of the KVM_SEV_INIT or KVM_SEV_ES_INIT. > > The flags value must be zero, it will be extended in future SNP support > to communicate the optional features (such as restricted INT injection > etc). We have a (preexisting) problem in that KVM_SEV_INIT and KVM_SEV_ES_INIT are not flexible enough. debug_swap has broken measurements of the VMSA because it changed the contents of the VMSA under userspace's feet, therefore VMSA features need to be passed into the API somehow. It's preexisting but we need to fix it before the new KVM_SNP_INIT API makes it worse. I have started prototyping a change to move SEV-ES/SEV-SNP to KVM_CREATE_VM, and introduce a single KVM_SEV_INIT_VM operation that can be used for the PSP initialization. > +The flags bitmap is defined as:: > + > + /* enable the restricted injection */ > + #define KVM_SEV_SNP_RESTRICTED_INJET (1<<0) > + > + /* enable the restricted injection timer */ > + #define KVM_SEV_SNP_RESTRICTED_TIMER_INJET (1<<1) These are not yet supported, so they might as well not be documented. If you want to document them, you need to provide an API to query SEV_SNP_SUPPORTED_FLAGS. Let's do that later. > + if (params.flags & ~SEV_SNP_SUPPORTED_FLAGS) > + ret = -EOPNOTSUPP; > + > + params.flags = SEV_SNP_SUPPORTED_FLAGS; This assignment is not necessary. Paolo
