From: Oliver Upton <oliver.upton@linux.dev>
To: Sean Christopherson <seanjc@google.com>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>,
Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Salil Mehta <salil.mehta@huawei.com>
Subject: Re: [PATCH 01/11] KVM: x86: Redefine 'longmode' as a flag for KVM_EXIT_HYPERCALL
Date: Tue, 21 Mar 2023 17:36:37 +0000 [thread overview]
Message-ID: <ZBnrJU0V/fP53k7a@linux.dev> (raw)
In-Reply-To: <ZBnTE5hCGUOSK3BW@google.com>
On Tue, Mar 21, 2023 at 08:53:55AM -0700, Sean Christopherson wrote:
> On Mon, Mar 20, 2023, Oliver Upton wrote:
> > The 'longmode' field is a bit annoying as it blows an entire __u32 to
> > represent a boolean value. Since other architectures are looking to add
> > support for KVM_EXIT_HYPERCALL, now is probably a good time to clean it
> > up.
> >
> > Redefine the field (and the remaining padding) as a set of flags.
> > Preserve the existing ABI by using the lower 32 bits of the field to
> > indicate if the guest was in long mode at the time of the hypercall.
>
> Setting all of bits 31:0 doesn't strictly preserve the ABI, e.g. will be a
> breaking change if userspace does something truly silly like
>
> if (vcpu->run->hypercall.longmode == true)
> ...
>
> It's likely unnecessary paranoia, but at the same time it's easy to avoid.
Argh, yeah. My route was just lazy.
> > Cc: Paolo Bonzini <pbonzini@redhat.com>
> > Cc: Sean Christopherson <seanjc@google.com>
> > Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
> > ---
> > arch/x86/include/uapi/asm/kvm.h | 9 +++++++++
> > arch/x86/kvm/x86.c | 5 ++++-
> > include/uapi/linux/kvm.h | 9 +++++++--
> > 3 files changed, 20 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
> > index 7f467fe05d42..ab7b7b1d7c9d 100644
> > --- a/arch/x86/include/uapi/asm/kvm.h
> > +++ b/arch/x86/include/uapi/asm/kvm.h
> > @@ -559,4 +559,13 @@ struct kvm_pmu_event_filter {
> > #define KVM_VCPU_TSC_CTRL 0 /* control group for the timestamp counter (TSC) */
> > #define KVM_VCPU_TSC_OFFSET 0 /* attribute for the TSC offset */
> >
> > +/*
> > + * x86-specific KVM_EXIT_HYPERCALL flags.
> > + *
> > + * KVM previously used a u32 field to indicate the hypercall was initiated from
> > + * long mode. As such, the lower 32 bits of the flags are used for long mode to
> > + * preserve ABI.
> > + */
> > +#define KVM_EXIT_HYPERCALL_LONG_MODE GENMASK_ULL(31, 0)
>
> For the uapi, I think it makes sense to do:
>
> #define KVM_EXIT_HYPERCALL_LONG_MODE BIT(0)
>
> and then somewhere internally do:
>
> /* Snarky comment goes here. */
> #define KVM_EXIT_HYPERCALL_MBZ GENMASK_ULL(31, 1)
>
> > #endif /* _ASM_X86_KVM_H */
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 7713420abab0..c61c2b0c73bd 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -9803,7 +9803,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
> > vcpu->run->hypercall.args[0] = gpa;
> > vcpu->run->hypercall.args[1] = npages;
> > vcpu->run->hypercall.args[2] = attrs;
> > - vcpu->run->hypercall.longmode = op_64_bit;
> > + vcpu->run->hypercall.flags = 0;
> > + if (op_64_bit)
> > + vcpu->run->hypercall.flags |= KVM_EXIT_HYPERCALL_LONG_MODE;
> > +
>
> And add a runtime assertion to make sure we don't botch this in the future:
>
> WARN_ON_ONCE(vcpu->run->hypercall.flags & KVM_EXIT_HYPERCALL_MBZ);
>
LGTM, I'll get something like this incorporated for v2.
--
Thanks,
Oliver
next prev parent reply other threads:[~2023-03-21 17:36 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-20 22:09 [PATCH 00/11] KVM: arm64: Userspace SMCCC call filtering Oliver Upton
2023-03-20 22:09 ` [PATCH 01/11] KVM: x86: Redefine 'longmode' as a flag for KVM_EXIT_HYPERCALL Oliver Upton
2023-03-21 15:53 ` Sean Christopherson
2023-03-21 17:36 ` Oliver Upton [this message]
2023-03-20 22:09 ` [PATCH 02/11] KVM: arm64: Add a helper to check if a VM has ran once Oliver Upton
2023-03-21 9:42 ` Suzuki K Poulose
2023-03-21 16:29 ` Oliver Upton
2023-03-20 22:09 ` [PATCH 03/11] KVM: arm64: Add vm fd device attribute accessors Oliver Upton
2023-03-21 9:53 ` Suzuki K Poulose
2023-03-21 16:49 ` Oliver Upton
2023-03-28 8:39 ` Suzuki K Poulose
2023-03-28 8:40 ` Suzuki K Poulose
2023-03-20 22:09 ` [PATCH 04/11] KVM: arm64: Rename SMC/HVC call handler to reflect reality Oliver Upton
2023-03-21 9:52 ` Suzuki K Poulose
2023-03-28 8:40 ` Suzuki K Poulose
2023-03-20 22:09 ` [PATCH 05/11] KVM: arm64: Start handling SMCs from EL1 Oliver Upton
2023-03-28 8:52 ` Suzuki K Poulose
2023-03-28 14:15 ` Marc Zyngier
2023-03-20 22:09 ` [PATCH 06/11] KVM: arm64: Refactor hvc filtering to support different actions Oliver Upton
2023-03-28 9:19 ` Suzuki K Poulose
2023-03-20 22:09 ` [PATCH 07/11] KVM: arm64: Use a maple tree to represent the SMCCC filter Oliver Upton
2023-03-20 22:09 ` [PATCH 08/11] KVM: arm64: Add support for KVM_EXIT_HYPERCALL Oliver Upton
2023-03-20 22:10 ` [PATCH 09/11] KVM: arm64: Indroduce support for userspace SMCCC filtering Oliver Upton
2023-03-20 22:10 ` [PATCH 10/11] KVM: selftests: Add a helper for SMCCC calls with SMC instruction Oliver Upton
2023-03-20 22:10 ` [PATCH 11/11] KVM: selftests: Add test for SMCCC filter Oliver Upton
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=ZBnrJU0V/fP53k7a@linux.dev \
--to=oliver.upton@linux.dev \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--cc=pbonzini@redhat.com \
--cc=salil.mehta@huawei.com \
--cc=seanjc@google.com \
--cc=suzuki.poulose@arm.com \
--cc=yuzenghui@huawei.com \
/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.