From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oupton@google.com>
Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
Peter Shier <pshier@google.com>,
Ricardo Koller <ricarkol@google.com>,
Jing Zhang <jingzhangos@google.com>,
Raghavendra Rao Anata <rananta@google.com>,
James Morse <james.morse@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Drew Jones <drjones@redhat.com>
Subject: Re: [PATCH 0/4] KVM: arm64: Fix some races in CPU_ON PSCI call
Date: Wed, 18 Aug 2021 12:32:54 +0100 [thread overview]
Message-ID: <87mtpfrnrt.wl-maz@kernel.org> (raw)
In-Reply-To: <20210818085047.1005285-1-oupton@google.com>
[+ Andrew for the selftest part.]
Hi Oliver,
On Wed, 18 Aug 2021 09:50:43 +0100,
Oliver Upton <oupton@google.com> wrote:
>
> The CPU_ON PSCI call requires careful coordination between vCPUs in KVM,
> as it allows callers to send a payload (pc, context id) to another vCPU
> to start execution. There are a couple of races in the handling of
> CPU_ON:
>
> - KVM uses the kvm->lock to serialize the write-side of a vCPU's reset
> state. However, kvm_vcpu_reset() doesn't take the lock on the
> read-size, meaning the vCPU could be reset with interleaved state
> from two separate CPU_ON calls.
>
> - If a targeted vCPU never enters the guest again (say, the VMM was
> getting ready to migrate), then the reset payload is never actually
> folded in to the vCPU's registers. Despite this, the calling vCPU has
> already made the target runnable. Migrating the target vCPU at this
> time will result in execution from its old PC, not execution coming
> out of the reset state at the requested address.
>
> Patch 1 addresses the read-side race in KVM's CPU_ON implementation.
>
> Patch 2 fixes the KVM/VMM race by resetting a vCPU (if requested)
> whenever the VMM tries to read out its registers. Gross, but it avoids
> exposing the vcpu_reset_state structure through some other UAPI. That is
> undesirable, as we really are only trying to paper over the
> implementation details of PSCI in KVM.
>
> Patch 3 is unrelated, and is based on my own reading of the PSCI
> specification. In short, if you invoke PSCI_ON from AArch64, then you
> must set the Aff3 bits. This is impossible if you use the 32 bit
> function, since the arguments are only 32 bits. Just return
> INVALID_PARAMS to the guest in this case.
Overall, this looks pretty good, and I only have a few nits on the
first three patches. I'll let Andrew comment on the selftest, which
looks OK to me at least on the surface.
>
> This series cleanly applies to kvm-arm/next at the following commit:
>
> ae280335cdb5 ("Merge branch kvm-arm64/mmu/el2-tracking into kvmarm-master/next")
>
Another nit: In the future, please consider basing your series on a
stable tag (such as v5.14-rc4), as kvmarm/next is a bit of a moving
target (the individual commits are stable, but the merge commits
aren't). Basing something off -next should be reserved for the cases
where you are fixing something that is only broken there.
Thanks,
M.
> The series was tested with the included KVM selftest on an Ampere Mt.
> Jade system. Broken behavior was verified using the same test on
> kvm-arm/next, sans this series.
>
> Oliver Upton (4):
> KVM: arm64: Fix read-side race on updates to vcpu reset state
> KVM: arm64: Handle PSCI resets before userspace touches vCPU state
> KVM: arm64: Enforce reserved bits for PSCI target affinities
> selftests: KVM: Introduce psci_cpu_on_test
>
> arch/arm64/kvm/arm.c | 9 ++
> arch/arm64/kvm/psci.c | 20 ++-
> arch/arm64/kvm/reset.c | 16 ++-
> tools/testing/selftests/kvm/.gitignore | 1 +
> tools/testing/selftests/kvm/Makefile | 1 +
> .../selftests/kvm/aarch64/psci_cpu_on_test.c | 121 ++++++++++++++++++
> .../selftests/kvm/include/aarch64/processor.h | 3 +
> 7 files changed, 162 insertions(+), 9 deletions(-)
> create mode 100644 tools/testing/selftests/kvm/aarch64/psci_cpu_on_test.c
>
--
Without deviation from the norm, progress is not possible.
prev parent reply other threads:[~2021-08-18 11:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-18 8:50 [PATCH 0/4] KVM: arm64: Fix some races in CPU_ON PSCI call Oliver Upton
2021-08-18 8:50 ` [PATCH 1/4] KVM: arm64: Fix read-side race on updates to vcpu reset state Oliver Upton
2021-08-18 10:06 ` Marc Zyngier
2021-08-18 8:50 ` [PATCH 2/4] KVM: arm64: Handle PSCI resets before userspace touches vCPU state Oliver Upton
2021-08-18 10:38 ` Marc Zyngier
2021-08-18 8:50 ` [PATCH 3/4] KVM: arm64: Enforce reserved bits for PSCI target affinities Oliver Upton
2021-08-18 11:12 ` Marc Zyngier
2021-08-18 8:50 ` [PATCH 4/4] selftests: KVM: Introduce psci_cpu_on_test Oliver Upton
2021-08-18 14:42 ` Andrew Jones
2021-08-18 11:32 ` Marc Zyngier [this message]
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=87mtpfrnrt.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=alexandru.elisei@arm.com \
--cc=drjones@redhat.com \
--cc=james.morse@arm.com \
--cc=jingzhangos@google.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=oupton@google.com \
--cc=pshier@google.com \
--cc=rananta@google.com \
--cc=ricarkol@google.com \
--cc=suzuki.poulose@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).