From: Greg KH <gregkh@linuxfoundation.org>
To: James Gowans <jgowans@amazon.com>
Cc: stable@vger.kernel.org, chenxiang66@hisilicon.com,
maz@kernel.org, oliver.upton@linux.dev, yuzenghui@huawei.com,
sironi@amazon.de
Subject: Re: [PATCH 5.15.y] KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t preemption
Date: Tue, 2 Jul 2024 12:41:34 +0200 [thread overview]
Message-ID: <2024070221-lurch-implode-229f@gregkh> (raw)
In-Reply-To: <20240701111933.41973-1-jgowans@amazon.com>
On Mon, Jul 01, 2024 at 01:19:33PM +0200, James Gowans wrote:
> From: Marc Zyngier <maz@kernel.org>
>
> Xiang reports that VMs occasionally fail to boot on GICv4.1 systems when
> running a preemptible kernel, as it is possible that a vCPU is blocked
> without requesting a doorbell interrupt.
>
> The issue is that any preemption that occurs between vgic_v4_put() and
> schedule() on the block path will mark the vPE as nonresident and *not*
> request a doorbell irq. This occurs because when the vcpu thread is
> resumed on its way to block, vcpu_load() will make the vPE resident
> again. Once the vcpu actually blocks, we don't request a doorbell
> anymore, and the vcpu won't be woken up on interrupt delivery.
>
> Fix it by tracking that we're entering WFI, and key the doorbell
> request on that flag. This allows us not to make the vPE resident
> when going through a preempt/schedule cycle, meaning we don't lose
> any state.
>
> Cc: stable@vger.kernel.org
> Fixes: 8e01d9a396e6 ("KVM: arm64: vgic-v4: Move the GICv4 residency flow to be driven by vcpu_load/put")
> Reported-by: Xiang Chen <chenxiang66@hisilicon.com>
> Suggested-by: Zenghui Yu <yuzenghui@huawei.com>
> Tested-by: Xiang Chen <chenxiang66@hisilicon.com>
> Co-developed-by: Oliver Upton <oliver.upton@linux.dev>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> Acked-by: Zenghui Yu <yuzenghui@huawei.com>
> Link: https://lore.kernel.org/r/20230713070657.3873244-1-maz@kernel.org
> Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
>
> (cherry picked from commit b321c31c9b7b309dcde5e8854b741c8e6a9a05f0)
>
> [modified to wrangle the vCPU flags directly instead of going through
> the flag helper macros as they have not yet been introduced. Also doing
> the flag wranging in the kvm_arch_vcpu_{un}blocking() hooks as the
> introduction of kvm_vcpu_wfi has not yet happened. See:
> 6109c5a6ab7f ("KVM: arm64: Move vGIC v4 handling for WFI out arch callback hook")]
>
> Signed-off-by: James Gowans <jgowans@amazon.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 1 +
> arch/arm64/kvm/arm.c | 6 ++++--
> arch/arm64/kvm/vgic/vgic-v3.c | 2 +-
> arch/arm64/kvm/vgic/vgic-v4.c | 8 ++++++--
> include/kvm/arm_vgic.h | 2 +-
> 5 files changed, 13 insertions(+), 6 deletions(-)
>
All now queued up.
greg k-h
prev parent reply other threads:[~2024-07-02 10:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-23 20:41 FAILED: patch "[PATCH] KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t" failed to apply to 5.15-stable tree gregkh
2024-07-01 11:19 ` [PATCH 5.15.y] KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t preemption James Gowans
2024-07-02 8:42 ` Marc Zyngier
2024-07-02 10:41 ` Greg KH [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=2024070221-lurch-implode-229f@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=chenxiang66@hisilicon.com \
--cc=jgowans@amazon.com \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=sironi@amazon.de \
--cc=stable@vger.kernel.org \
--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.