From: Oliver Upton <oliver.upton@linux.dev>
To: Raghavendra Rao Ananta <rananta@google.com>
Cc: Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Will Deacon <will@kernel.org>, Fuad Tabba <tabba@google.com>,
Jing Zhang <jingzhangos@google.com>,
Colton Lewis <coltonlewis@google.com>,
Reiji Watanabe <reijiw@google.com>,
kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: arm64: Fix CPUHP logic for protected KVM
Date: Wed, 19 Jul 2023 20:48:13 +0000 [thread overview]
Message-ID: <ZLhMDapXa2djVzf0@linux.dev> (raw)
In-Reply-To: <20230719175400.647154-1-rananta@google.com>
On Wed, Jul 19, 2023 at 05:54:00PM +0000, Raghavendra Rao Ananta wrote:
> For protected kvm, the CPU hotplug 'down' logic currently brings
> down the timer and vGIC, essentially disabling interrupts. However,
> because of how the 'kvm_arm_hardware_enabled' flag is designed, it
> never re-enables them back on the CPU hotplug 'up' path. Hence,
> clean up the logic to maintain the CPU hotplug up/down symmetry.
Correct me if I am wrong, but this issue exists outside of cpu hotplug,
right? init_subsystems() calls _kvm_arch_hardware_enable() on all cores,
which only sets up the hyp cpu context and not the percpu interrupts.
Similar issue exists for the cpu that calls do_pkvm_init().
I'll also note kvm_arm_hardware_enabled is deceptively vague, as it only
keeps track of whether or not the hyp cpu context has been initialized.
May send a cleanup here in a bit.
Perhaps this for the changelog:
KVM: arm64: Fix hardware enable/disable flows for pKVM
When running in protected mode, the hyp stub is disabled after pKVM is
initialized, meaning the host cannot enable/disable the hyp at
runtime. As such, kvm_arm_hardware_enabled is always 1 after
initialization, and kvm_arch_hardware_enable() never enables the vgic
maintenance irq or timer irqs.
Unconditionally enable/disable the vgic + timer irqs in the respective
calls, instead relying on the percpu bookkeeping in the generic code
to keep track of which cpus have the interrupts unmasked.
> Fixes: 466d27e48d7c ("KVM: arm64: Simplify the CPUHP logic")
> Reported-by: Oliver Upton <oliver.upton@linux.dev>
> Suggested-by: Oliver Upton <oliver.upton@linux.dev>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/kvm/arm.c | 14 ++++----------
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index c2c14059f6a8..010ebfa69650 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -1867,14 +1867,10 @@ static void _kvm_arch_hardware_enable(void *discard)
>
> int kvm_arch_hardware_enable(void)
> {
> - int was_enabled = __this_cpu_read(kvm_arm_hardware_enabled);
> -
> _kvm_arch_hardware_enable(NULL);
>
> - if (!was_enabled) {
> - kvm_vgic_cpu_up();
> - kvm_timer_cpu_up();
> - }
> + kvm_vgic_cpu_up();
> + kvm_timer_cpu_up();
>
> return 0;
> }
> @@ -1889,10 +1885,8 @@ static void _kvm_arch_hardware_disable(void *discard)
>
> void kvm_arch_hardware_disable(void)
> {
> - if (__this_cpu_read(kvm_arm_hardware_enabled)) {
> - kvm_timer_cpu_down();
> - kvm_vgic_cpu_down();
> - }
> + kvm_timer_cpu_down();
> + kvm_vgic_cpu_down();
>
> if (!is_protected_kvm_enabled())
> _kvm_arch_hardware_disable(NULL);
> --
> 2.41.0.487.g6d72f3e995-goog
>
--
Thanks,
Oliver
next prev parent reply other threads:[~2023-07-19 20:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-19 17:54 [PATCH] KVM: arm64: Fix CPUHP logic for protected KVM Raghavendra Rao Ananta
2023-07-19 20:48 ` Oliver Upton [this message]
2023-07-19 21:16 ` Raghavendra Rao Ananta
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=ZLhMDapXa2djVzf0@linux.dev \
--to=oliver.upton@linux.dev \
--cc=coltonlewis@google.com \
--cc=james.morse@arm.com \
--cc=jingzhangos@google.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=rananta@google.com \
--cc=reijiw@google.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@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.