All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Donnefort <vdonnefort@google.com>
To: Fuad Tabba <fuad.tabba@linux.dev>
Cc: maz@kernel.org, oupton@kernel.org, kvmarm@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com,
	seiden@linux.ibm.com, suzuki.poulose@arm.com,
	yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
	kernel-team@android.com, tabba@google.com
Subject: Re: [PATCH v2 2/4] KVM: arm64: pkvm: Fix missing reset of GICv3 LRs
Date: Fri, 23 Oct 2026 08:59:29 +0100	[thread overview]
Message-ID: <atsT4c-JLRSxSreo@google.com> (raw)
In-Reply-To: <20261022173604.3710390-1-fuad.tabba@linux.dev>

On Thu, Oct 22, 2026 at 06:36:04PM +0100, Fuad Tabba wrote:
> Hi Vincent,
> 
> On Thu, 22 Oct 2026 15:00:46 +0100, Vincent Donnefort <vdonnefort@google.com> wrote:
> > The vGIC LRs are architecturally UNKNOWN when the CPU boots or resumes.
> > However, in protected mode, only the used ones are reset, because the
> > HVC __vgic_v3_init_lrs() is never called:
> 
> Could you say here what happens to a guest when an LR isn't reset, as I
> asked on v1? Without this series, on QEMU changed to leave a pending
> vINTID 100 in the top LR at CPU reset, the guest warns "Unexpected
> interrupt (irqnr 100)". With only the EOI bit set there, the npVM
> doesn't print anything in 150 seconds, since the maintenance interrupt
> is asserted on every entry. With that in the message, could you also
> bring back the Cc: stable you had on v1?

Sorry I missed that.

Actually I don't know if this should be backported. I believe it was working
until now because all SoCs do reset their LRs even though they don't have to do
it.

-- 
Vincent

> 
> [...]
> > Then, cpu_hyp_init() is only called from init_subsystems and
> > kvm_arch_enable_virtualization_cpu(). Remove the kvm_hyp_initialized
> > gate: when pKVM is enabled, the cpu_hyp_reset() will just return an
> > error while for other modes, we already know kvm_hyp_initialized is
> > false at this point.
> 
> In init_subsystems(), only the CPU that ran do_pkvm_init() returns an
> error here. The others are still on the hyp stub, which returns 0 for
> HVC_RESET_VECTORS, so they go through the full init. Could you reword
> this part?
> 
> [...]
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> [...]
> >  static void cpu_hyp_reinit(void)
> >  {
> > -        cpu_hyp_reset();
> > -        cpu_hyp_init_context();
> > -        cpu_hyp_init_features();
> > +        if (!cpu_hyp_reset()) {
> > +                cpu_hyp_init_context();
> > +                cpu_hyp_init_features();
> > +        } else {
> > +                if (WARN_ON(!__this_cpu_read(kvm_hyp_initialized)))
> > +                        return;
> > +        }
> 
> Could you make this "} else if (WARN_ON(...)) {", as elsewhere in
> arm.c?
> 
> > +
> > +        /*
> > +         * Even if the hypervisor didn't allow resetting the vectors we can
> > +         * reset what we have access to.
> > +         */
> 
> nit: "what we have access to" is the LRs, so I'd name them.
> 
> With the above addressed:
> Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
> Tested-by: Fuad Tabba <fuad.tabba@linux.dev>
> 
> Cheers,
> /fuad

  reply	other threads:[~2026-10-23  7:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-22 14:00 [PATCH v2 0/4] KVM: arm64: pkvm: Fix missing reset of GICv3 LRs Vincent Donnefort
2026-10-22 14:00 ` [PATCH v2 1/4] KVM: arm64: Make __vgic_v3_init_lrs HVC always available Vincent Donnefort
2026-10-22 17:34   ` Fuad Tabba
2026-10-22 14:00 ` [PATCH v2 2/4] KVM: arm64: pkvm: Fix missing reset of GICv3 LRs Vincent Donnefort
2026-10-22 17:36   ` Fuad Tabba
2026-10-23  7:59     ` Vincent Donnefort [this message]
2026-10-23  8:14       ` Fuad Tabba
2026-10-22 14:00 ` [PATCH v2 3/4] KVM: arm64: pkvm: Reset GICv3 LRs in the hypervisor Vincent Donnefort
2026-10-22 17:37   ` Fuad Tabba
2026-10-22 14:00 ` [PATCH v2 4/4] KVM: arm64: pkvm: Avoid trapping on HVC_RESET_VECTORS Vincent Donnefort
2026-10-22 17:38   ` Fuad Tabba
2026-10-23  8:01     ` Vincent Donnefort

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=atsT4c-JLRSxSreo@google.com \
    --to=vdonnefort@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=fuad.tabba@linux.dev \
    --cc=joey.gouly@arm.com \
    --cc=kernel-team@android.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=seiden@linux.ibm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=will@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.