[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v7yevlyc.wl-maz@kernel.org>
Date: Sun, 29 Sep 2024 10:38:35 +0100
From: Marc Zyngier <maz@...nel.org>
To: jiaqingtong97@...il.com
Cc: Oliver Upton <oliver.upton@...ux.dev>,
James Morse <james.morse@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Zenghui Yu <yuzenghui@...wei.com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Joey Gouly <joey.gouly@....com>,
Jia Qingtong <jiaqingtong@...wei.com>,
linux-arm-kernel@...ts.infradead.org,
kvmarm@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: arm64: vgic: fix GICR_STATUSR in vgic_v3_rd_registers
On Sun, 29 Sep 2024 05:39:35 +0100,
jiaqingtong97@...il.com wrote:
>
> From: Jia Qingtong <jiaqingtong@...wei.com>
>
> vgic_uaccess use bsearch search regs in vgic_io_device.regions, but the
> GICR_STATUSR have wrong order in vgic_v3_rd_registers.
> When check all vgic_register_region, it turned out that only
> vgic_v3_rd_registers has this problem.
>
> It's harmless since vgic_uaccess behaves as RAZ&WI when it can't find the
> specified reg. This is exactly the same as the behavior of the GICR_STATUSR
> register.
>
> So just move GICR_STATUSR to the right place.
That looks correct, but I think we should have some code that ensures
that these tables are correct at boot time, just like we're doing for
the system registers. Or completely remove our reliance on bsearch().
Another thing is that GICD_STATUSR looks pretty wrong. It is handled
as RAO, but we never clear any "error" (it is WI). This has been buggy
since GICv3 save/restore was added, 7 years ago.
Do you mind spinning a series fixing this up?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists