On Mon, Jul 19, 2021 at 9:54 AM Sean Christopherson [off-list ref] wrote:

On Fri, Jul 16, 2021, Brijesh Singh wrote:

quoted

On 7/16/21 3:18 PM, Sean Christopherson wrote:

quoted

On Wed, Jul 07, 2021, Brijesh Singh wrote:

quoted

+  data->gctx_paddr = __psp_pa(sev->snp_context);
+  ret = sev_issue_cmd(kvm, SEV_CMD_SNP_LAUNCH_FINISH, data, &argp->error);

Shouldn't KVM unwind everything it did if LAUNCH_FINISH fails?  And if that's
not possible, take steps to make the VM unusable?

Well, I am not sure if VM need to unwind. If the command fail but VMM decide
to ignore the error then VMRUN will probably fail and user will get the KVM
shutdown event. The LAUNCH_FINISH command finalizes the VM launch process,
the firmware will probably not load the memory encryption keys until it moves
to the running state.

Within reason, KVM needs to provide consistent, deterministic behavior.  Yes, more
than likely failure at this point will be fatal to the VM, but that doesn't justify
leaving the VM in a random/bogus state.  In addition to being a poor ABI, it also
makes it more difficult to reason about what is/isn't possible in KVM.

+1 to Sean's feedback to unwind everything here properly here.
Comments of the nature of "XYZ should happen" -- without a test (e.g.,
selftest or kvm-unit-test) to ensure the XYZ _does_ happen -- are a
time bomb waiting to happen.

Also, I wonder if we leave pages, RMPUPDATE'd to immutable in previous
loop iterations, is it possible for them to remain as immutable and be
reused later on (after this guest is destroyed)? And if this happens,
will we get an RMP violation? Even if the answer is no -- go read this
code 2,000 lines away -- it handles this case. That's still not a very
satisfying answer. I'd rather see things cleaned up ASAP as soon as
the code starts to go off the rails.