All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oupton@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: Marc Zyngier <maz@kernel.org>, kvmarm@lists.linux.dev
Subject: Re: [PATCH v3 3/5] KVM: arm64: nv: Re-translate VNCR before injecting abort
Date: Mon, 22 Jun 2026 10:18:11 -0700	[thread overview]
Message-ID: <ajluUzbMsicbJ5Ci@kernel.org> (raw)
In-Reply-To: <20260619000034.7F2511F000E9@smtp.kernel.org>

On Fri, Jun 19, 2026 at 12:00:33AM +0000, sashiko-bot@kernel.org wrote:
> > -			handle_vncr_perm(vcpu);
> > -			break;
> > -		case 0:
> > -			break;
> > -		}
> > -	} else {
> > -		WARN_ONCE(1, "Unhandled VNCR abort, ESR=%llx\n", esr);
> > +	case 0:
> > +		perm = kvm_is_write_fault(vcpu) ? vt->wr.pw && vt->hpa_writable : vt->wr.pr;
> > +		if (!perm)
> >  			handle_vncr_perm(vcpu);
> > +		break;
> >  	}
> >  
> >  	return 1;
> 
> [Severity: High]
> Does removing the -EPERM loop breaker introduce a host CPU livelock for
> Write-Only guest VNCR mappings?
> 
> If the guest configures a Write-Only mapping, kvm_map_l1_vncr() falls back
> to mapping it as PAGE_NONE. When the hardware accesses the fixmap, it triggers
> a Data Abort. KVM then traps and re-translates the mapping.
> 
> Because vt->wr.pw is true, the perm check evaluates to true, and KVM returns 1
> to resume the guest instead of injecting a fault. The hardware will then fault
> again indefinitely.

Advertising NV2 to the VM should've been conditioned on hiding S1PIE
because there's no way to fix this. As the access passes the guest
permission check, we have no fault that can be injected for stage-1.

> [Severity: High]
> Also, does calling kvm_translate_vncr() unconditionally request FOLL_WRITE
> on a write fault without verifying if the guest's own Stage-1 mapping
> actually permits writes?
> 
> In kvm_translate_vncr(), __kvm_faultin_pfn() is called with FOLL_WRITE if it's
> a write fault. If the host memslot happens to be read-only, __kvm_faultin_pfn()
> fails and returns -EFAULT.
> 
> This error bubbles up to the switch statement above, which injects an External
> Abort into the guest. Should the guest instead receive a Stage-1 Permission
> Fault if its own Stage-1 translation does not permit writes, regardless of the
> memslot permissions?

Again, this is below the bar of stable fixes (intent of this series).

Thanks,
Oliver

  reply	other threads:[~2026-06-22 17:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-18 23:42 [PATCH v3 0/5] KVM: arm64: nv: Even more VNCR fixes Oliver Upton
2026-06-18 23:42 ` [PATCH v3 1/5] KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR Oliver Upton
2026-06-19  0:07   ` sashiko-bot
2026-06-22 17:10     ` Oliver Upton
2026-06-18 23:42 ` [PATCH v3 2/5] KVM: arm64: nv: Inject SEA if kvm_translate_vncr() can't resolve PFN Oliver Upton
2026-06-18 23:57   ` sashiko-bot
2026-06-18 23:42 ` [PATCH v3 3/5] KVM: arm64: nv: Re-translate VNCR before injecting abort Oliver Upton
2026-06-19  0:00   ` sashiko-bot
2026-06-22 17:18     ` Oliver Upton [this message]
2026-06-18 23:42 ` [PATCH v3 4/5] KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory Oliver Upton
2026-06-18 23:42 ` [PATCH v3 5/5] KVM: arm64: nv: Mark VM as bugged for unexpected VNCR abort Oliver Upton

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=ajluUzbMsicbJ5Ci@kernel.org \
    --to=oupton@kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.