Re: [PATCH RESEND v2 3/5] KVM: arm64: nv: Re-translate VNCR before injecting abort

[Oliver Upton <oupton@kernel.org>]

Hey Wei-Lin,

Sorry for the latency on my end.

On Wed, Jun 10, 2026 at 02:46:18PM +0100, Wei-Lin Chang wrote:
> Just a comment using this thread:
> 
> While reading this, I found this part of the code (not this patch in
> particular) a little bit difficult to reason about. I think it's because
> kvm_translate_vncr() is doing many things, and there are multiple
> potential failure reasons e.g. s1 walk fault, no memslot, gmem/user mem
> faultin errors, MMU notifier check, etc., and they are all mux'ed into
> an error code with some context visible by the caller.
> 
> So in kvm_handle_vncr_abort() we demux the error code and handle the
> errors with the help of the context (vt, is_gmem). We essentially have
> to keep track of what error codes correspond to what error reasons.
> 
> Do you think it is better if we refactor and handle the errors when they
> occur? Like inject the exception back to vEL2 right after getting the
> results of __kvm_translate_va(), and finish up the abort handling there.
> Same for other cases.
> 
> I can try it out and make it concrete if you also think this is
> reasonable. Probably after this series gets applied when the comments
> from Marc & Sashiko are addressed. (I reviewed and don't have additional
> comments though.)

Yeah, returning error codes for 'normal' behavior is extremely difficult
to work with. TBH, I'd rather we go a step further and rework the whole
software PTW to only return errors in the case that we have to report it
to userspace.

Otherwise, aborted walks due to guest behavior should ideally return 1
and and inspect the walk result to differentiate between a successful /
aborted translation.

Thanks,
Oliver