From: Sean Christopherson <seanjc@google.com>
To: Peter Gonda <pgonda@google.com>
Cc: kvm list <kvm@vger.kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Anup Patel <anup@brainfault.org>, Will Deacon <will@kernel.org>
Subject: Re: [PATCH v4.1] KVM, SEV: Add KVM_EXIT_SHUTDOWN metadata for SEV-ES
Date: Fri, 8 Apr 2022 17:01:21 +0000 [thread overview]
Message-ID: <YlBqYcXFiwur3zmo@google.com> (raw)
In-Reply-To: <CAMkAt6oc=SOYryXu+_w+WZR+VkMZfLR3_nd=hDvMU_cmOjJ0Xg@mail.gmail.com>
+Anup and Will
On Fri, Apr 08, 2022, Peter Gonda wrote:
> On Thu, Apr 7, 2022 at 8:55 PM Sean Christopherson <seanjc@google.com> 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?
Yeah, both came in for v5.18. Given that there will be multiple paths that need
to set data, it's worth adding a common helper to the dirty work.
Anup and Will,
system_event.flags is broken (at least on x86) due to the prior 'type' field not
being propery padded, e.g. userspace will read/write garbage if the userspace
and kernel compilers pad structs differently.
struct {
__u32 type;
__u64 flags;
} system_event;
Our plan to unhose this is to change the struct as follows and use bit 31 in the
'type' to indicate that ndata+data are valid.
struct {
__u32 type;
__u32 ndata;
__u64 data[16];
} system_event;
Any objection to updating your architectures to use a helper to set the bit and
populate ndata+data accordingly? It'll require a userspace update, but v5.18
hasn't officially released yet so it's not kinda sort not ABI breakage.
next prev parent reply other threads:[~2022-04-08 17:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-07 21:02 [PATCH v4.1] KVM, SEV: Add KVM_EXIT_SHUTDOWN metadata for SEV-ES Peter Gonda
2022-04-08 2:55 ` Sean Christopherson
2022-04-08 15:18 ` Peter Gonda
2022-04-08 17:01 ` Sean Christopherson [this message]
2022-04-11 9:12 ` Will Deacon
2022-04-11 14:00 ` Alexandru Elisei
2022-04-11 15:06 ` Sean Christopherson
2022-04-14 23:21 ` Sean Christopherson
2022-04-08 4:34 ` kernel test robot
2022-04-08 5:15 ` kernel test robot
2022-04-08 16:56 ` Paolo Bonzini
2022-04-11 9:45 ` Marc Zyngier
2022-04-11 14:25 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YlBqYcXFiwur3zmo@google.com \
--to=seanjc@google.com \
--cc=anup@brainfault.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=pgonda@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.