Re: [PATCH] KVM: arm64: Fix nVHE stacktrace VA bits mask

[Vincent Donnefort <vdonnefort@google.com>]

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@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.