On Thu, Apr 7, 2022 at 8:55 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Thu, Apr 07, 2022, Peter Gonda wrote:
> > If an SEV-ES guest requests termination, exit to userspace with
> > KVM_EXIT_SYSTEM_EVENT and a dedicated SEV_TERM type instead of -EINVAL
> > so that userspace can take appropriate action.
> >
> > See AMD's GHCB spec section '4.1.13 Termination Request' for more details.
>
> Maybe it'll be obvious by the lack of compilation errors, but the changelog should
> call out the flags => ndata+data shenanigans, otherwise this looks like ABI breakage.
Hmm I am not sure we can do this change anymore given that we have two
call sites using 'flags'
arch/arm64/kvm/psci.c:184
arch/riscv/kvm/vcpu_sbi.c:97
I am not at all familiar with ARM and RISC-V but some quick reading
tells me these archs also require 64-bit alignment on their 64-bit
accesses. If thats correct, should I fix this call sites up by
proceeding with this ndata + data[] change and move whatever they are
assigning to flags into data[0] like I am doing here? It looks like
both of these changes are not in a kernel release so IIUC we can still
fix the ABI here?
>
> > Suggested-by: Sean Christopherson <seanjc@xxxxxxxxxx>
> > Suggested-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> > Cc: kvm@xxxxxxxxxxxxxxx
> > Cc: linux-kernel@xxxxxxxxxxxxxxx
> > Signed-off-by: Peter Gonda <pgonda@xxxxxxxxxx>
> >
> > ---
> > V4
> > * Updated to Sean and Paolo's suggestion of reworking the
> > kvm_run.system_event struct to ndata and data fields to fix the
> > padding.
> > * 4.1 Updated commit description
> >
> > V3
> > * Add Documentation/ update.
> > * Updated other KVM_EXIT_SHUTDOWN exits to clear ndata and set reason
> > to KVM_SHUTDOWN_REQ.
> >
> > V2
> > * Add KVM_CAP_EXIT_SHUTDOWN_REASON check for KVM_CHECK_EXTENSION.
> >
> > Tested by making an SEV-ES guest call sev_es_terminate() with hardcoded
> > reason code set and reason code and then observing the codes from the
> > userspace VMM in the kvm_run.shutdown.data fields.
> >
> > ---
> > arch/x86/kvm/svm/sev.c | 9 +++++++--
> > include/uapi/linux/kvm.h | 5 ++++-
> > 2 files changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> > index 75fa6dd268f0..1a080f3f09d8 100644
> > --- a/arch/x86/kvm/svm/sev.c
> > +++ b/arch/x86/kvm/svm/sev.c
> > @@ -2735,8 +2735,13 @@ static int sev_handle_vmgexit_msr_protocol(struct vcpu_svm *svm)
> > pr_info("SEV-ES guest requested termination: %#llx:%#llx\n",
> > reason_set, reason_code);
> >
> > - ret = -EINVAL;
> > - break;
> > + vcpu->run->exit_reason = KVM_EXIT_SYSTEM_EVENT;
> > + vcpu->run->system_event.type = KVM_SYSTEM_EVENT_SEV_TERM |
> > + KVM_SYSTEM_EVENT_NDATA_VALID;
> > + vcpu->run->system_event.ndata = 1;
> > + vcpu->run->system_event.data[1] = control->ghcb_gpa;
> > +
> > + return 0;
>
> Kinda silly, but
>
> ret = 0;
> break;
>
> would be better so that this flows through the tracepoint. I wouldn't care much
> if it didn't result in an unpaired "entry" tracepoint (and I still don't care that
> much...).
Ah I'll fix that up.
>
> > }
> > default:
> > /* Error, keep GHCB MSR value as-is */
> > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > index 8616af85dc5d..dd1d8167e71f 100644
> > --- a/include/uapi/linux/kvm.h
> > +++ b/include/uapi/linux/kvm.h
> > @@ -444,8 +444,11 @@ struct kvm_run {
> > #define KVM_SYSTEM_EVENT_SHUTDOWN 1
> > #define KVM_SYSTEM_EVENT_RESET 2
> > #define KVM_SYSTEM_EVENT_CRASH 3
> > +#define KVM_SYSTEM_EVENT_SEV_TERM 4
> > +#define KVM_SYSTEM_EVENT_NDATA_VALID (1u << 31)
> > __u32 type;
> > - __u64 flags;
> > + __u32 ndata;
> > + __u64 data[16];
> > } system_event;
> > /* KVM_EXIT_S390_STSI */
> > struct {
> > --
> > 2.35.1.1178.g4f1659d476-goog
> >
