[PATCH] KVM: arm64: Fix nVHE stacktrace VA bits mask
Vincent Donnefort
vdonnefort at google.com
Tue Jan 7 02:34:58 PST 2025
On Tue, Jan 07, 2025 at 09:31:16AM +0000, Marc Zyngier wrote:
> Vincent,
>
> Please add all the KVM/arm64 reviewers in the future (I added them
> this time).
Ack, apologies for the missing recipients.
>
> On Mon, 06 Jan 2025 18:32:13 +0000,
> Vincent Donnefort <vdonnefort at google.com> wrote:
> >
> > The hypervisor VA space size depends on both the ID map's
> > (IDMAP_VA_BITS) and the kernel stage-1 (VA_BITS). When VA_BITS is
> > smaller than IDMAP_VA_BITS (i.e. 39-bit), the stacktrace can contain
> > addresses bigger than the current VA_BITS mask.
> >
> > As the hyp_va_bits value needs to be used outside of the init code now,
> > use a global variable, shared by all the kvm users in mmu.c, arm.c and
> > now stacktrace.c.
>
> I tend to dislike this approach for at least three reasons:
>
> - it makes it hard to follow *when* hyp_va_bits is made valid, while
> passing the value as a parameter is self explanatory. Specially
> given how convoluted the nVHE/pKVM init is these days.
>
> - it prevents the eventual use of *multiple* VA bit values (one for
> TTBR0, one for TTBR1) once the grand plan for hVHE is completed
> (right after full NV support is merged! ;-)
>
> - it makes the change larger than it should be, specially for
> something that should be backported.
I was myself not completely convinced because of that last point. I'll send a v2
with a shorter version.
Thanks for your swift review!
>
> So I'd rather you keep the general shape of the code as it, and simply
> publish this 'hyp_va_bits' for the purpose of the backtrace code.
>
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
More information about the linux-arm-kernel
mailing list