From: Oliver Upton <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.linux.dev, Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Jiaqi Yan <jiaqiyan@google.com>
Subject: Re: [PATCH 3/3] KVM: arm64: Don't translate FAR if invalid/unsafe
Date: Wed, 2 Apr 2025 09:37:57 -0700 [thread overview]
Message-ID: <Z-1n5V5wqDTdXDq-@linux.dev> (raw)
In-Reply-To: <87friqzrfz.wl-maz@kernel.org>
Hey,
On Wed, Apr 02, 2025 at 01:19:28PM +0100, Marc Zyngier wrote:
> On Tue, 01 Apr 2025 23:42:34 +0100,
> Oliver Upton <oliver.upton@linux.dev> wrote:
> > static __always_inline phys_addr_t kvm_vcpu_get_fault_ipa(const struct kvm_vcpu *vcpu)
> > {
> > - return ((phys_addr_t)vcpu->arch.fault.hpfar_el2 & HPFAR_EL2_FIPA) << 8;
> > + u64 hpfar = vcpu->arch.fault.hpfar_el2;
> > +
> > + if (unlikely(!(hpfar & HPFAR_EL2_NS)))
> > + return INVALID_GPA;
>
> Eh, why not ;-)
>
> > +
> > + return ((phys_addr_t)hpfar & HPFAR_EL2_FIPA) << 8;
>
> nit: as you are reworking this area, I'd rather see
>
> return FIELD_GET(HPFAR_EL2_FIPA, hpfar) << 12;
>
> as it nicely shows what the FIPA field represents, instead of the
> odd-looking 8 here. The compiler will nicely sort it out anyway.
>
> Same thing in handle_host_mem_abort(), both of which could be fixed in
> the previous patch.
Agreed, this reads better.
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 2feb6c6b63af..754f2fe0cc67 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -1794,9 +1794,28 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
> > gfn_t gfn;
> > int ret, idx;
> >
> > + /* Synchronous External Abort? */
> > + if (kvm_vcpu_abt_issea(vcpu)) {
> > + /*
> > + * For RAS the host kernel may handle this abort.
> > + * There is no need to pass the error into the guest.
> > + */
> > + if (kvm_handle_guest_sea())
> > + kvm_inject_vabt(vcpu);
> > +
> > + return 1;
> > + }
> > +
>
> Maybe add a line to the commit message to indicate that you're moving
> this around?
I had this:
Finally, fix up the rest of the abort path by checking for SEAs early
and bugging the VM if we get further along with an UNKNOWN fault IPA.
But I'm happy to expand a bit to make that more clear.
> > esr = kvm_vcpu_get_esr(vcpu);
> >
> > + /*
> > + * The fault IPA should be reliable at this point as we're not dealing
> > + * with an SEA.
> > + */
> > ipa = fault_ipa = kvm_vcpu_get_fault_ipa(vcpu);
> > + if (KVM_BUG_ON(ipa == INVALID_GPA, vcpu->kvm))
> > + return -EFAULT;
> > +
>
> I think you're missing something similar in handle_host_mem_abort(),
> which will take fault.hpfar_el2 at face value even when it is unsafe
> to translate. At least testing for HPFAR_EL2_NS seems necessary.
Good point, I'll respin in a moment.
Thanks for having a look!
Best,
Oliver
next prev parent reply other threads:[~2025-04-02 16:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-01 22:42 [PATCH 0/3] KVM: arm64: Fixes for resolving the fault IPA Oliver Upton
2025-04-01 22:42 ` [PATCH 1/3] KVM: arm64: Only read HPFAR_EL2 when value is architecturally valid Oliver Upton
2025-04-02 11:15 ` Marc Zyngier
2025-04-02 11:30 ` Marc Zyngier
2025-04-02 16:39 ` Oliver Upton
2025-04-01 22:42 ` [PATCH 2/3] arm64: Convert HPFAR_EL2 to sysreg table Oliver Upton
2025-04-01 22:42 ` [PATCH 3/3] KVM: arm64: Don't translate FAR if invalid/unsafe Oliver Upton
2025-04-02 12:19 ` Marc Zyngier
2025-04-02 16:37 ` Oliver Upton [this message]
2025-04-02 17:01 ` Marc Zyngier
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=Z-1n5V5wqDTdXDq-@linux.dev \
--to=oliver.upton@linux.dev \
--cc=jiaqiyan@google.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--cc=suzuki.poulose@arm.com \
/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.