From: Oliver Upton <oliver.upton@linux.dev>
To: James Morse <james.morse@arm.com>
Cc: Marc Zyngier <maz@kernel.org>,
Ruidong Tian <tianruidong@linux.alibaba.com>,
kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org
Subject: Re: [PATCH] KVM: arm64: Add missing ERX*_EL1 registers
Date: Tue, 16 Jan 2024 16:38:41 +0100 [thread overview]
Message-ID: <ZaajAQafAnOgB8ho@linux.dev> (raw)
In-Reply-To: <67b15918-e9d3-97ea-65ca-985b5ddb3f88@arm.com>
Hi James,
On Mon, Jan 15, 2024 at 05:21:19PM +0000, James Morse wrote:
> Hi Oliver,
>
> On 15/01/2024 14:47, Oliver Upton wrote:
> > On Wed, Jan 10, 2024 at 12:20:30PM +0000, Marc Zyngier wrote:
> >> If my reading of the ARM ARM is correct, these registers only exist if
> >> FEAT_RASv1p1 is implemented. Which means that we shouldn't handle
> >> those as RAZ/WI unconditionally, but instead check for what we
> >> advertise to the guest and handle it accordingly.
> >
> > Can we go a step further and just stop advertising RAS to guests? I don't
> > expect VMs to gain much from our RAZ/WI implementation.
>
> These CPU registers would describe the error in a kernel-first setup, but firmware-first
> has its own in-memory way of doing that.
>
> The CPU features indicates the IESB feature and ESB-instruction exist to fence errors, and
> that the CPU uses the ESR_ELx.{S,A}ET bits to describe the CPU state after an error. These
> are all useful as part of the notification of an error, be that kernel-first or
> firmware-first.
>
> When its supported by the hardware, the VMM can inject an asynchronous external abort
> using KVM_GET_VCPU_EVENTS - otherwise the ESR_ELx.ISS bits are all imp-def, meaning all
> errors are catastrophic.
>
> Doing this would skip save/restore of VDISR_EL2, is there any other reason to do it?
Forgive me, had the blinders on and was thinking only of the error
record interface, not ESB/DISR. In that context it makes a lot less
sense to hide RAS from guests, especially if the guest depends on ESB
being a NOP if the hardware doesn't support it.
--
Thanks,
Oliver
WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oliver.upton@linux.dev>
To: James Morse <james.morse@arm.com>
Cc: Marc Zyngier <maz@kernel.org>,
Ruidong Tian <tianruidong@linux.alibaba.com>,
kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org
Subject: Re: [PATCH] KVM: arm64: Add missing ERX*_EL1 registers
Date: Tue, 16 Jan 2024 16:38:41 +0100 [thread overview]
Message-ID: <ZaajAQafAnOgB8ho@linux.dev> (raw)
In-Reply-To: <67b15918-e9d3-97ea-65ca-985b5ddb3f88@arm.com>
Hi James,
On Mon, Jan 15, 2024 at 05:21:19PM +0000, James Morse wrote:
> Hi Oliver,
>
> On 15/01/2024 14:47, Oliver Upton wrote:
> > On Wed, Jan 10, 2024 at 12:20:30PM +0000, Marc Zyngier wrote:
> >> If my reading of the ARM ARM is correct, these registers only exist if
> >> FEAT_RASv1p1 is implemented. Which means that we shouldn't handle
> >> those as RAZ/WI unconditionally, but instead check for what we
> >> advertise to the guest and handle it accordingly.
> >
> > Can we go a step further and just stop advertising RAS to guests? I don't
> > expect VMs to gain much from our RAZ/WI implementation.
>
> These CPU registers would describe the error in a kernel-first setup, but firmware-first
> has its own in-memory way of doing that.
>
> The CPU features indicates the IESB feature and ESB-instruction exist to fence errors, and
> that the CPU uses the ESR_ELx.{S,A}ET bits to describe the CPU state after an error. These
> are all useful as part of the notification of an error, be that kernel-first or
> firmware-first.
>
> When its supported by the hardware, the VMM can inject an asynchronous external abort
> using KVM_GET_VCPU_EVENTS - otherwise the ESR_ELx.ISS bits are all imp-def, meaning all
> errors are catastrophic.
>
> Doing this would skip save/restore of VDISR_EL2, is there any other reason to do it?
Forgive me, had the blinders on and was thinking only of the error
record interface, not ESB/DISR. In that context it makes a lot less
sense to hide RAS from guests, especially if the guest depends on ESB
being a NOP if the hardware doesn't support it.
--
Thanks,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-01-16 15:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-10 7:57 [PATCH] KVM: arm64: Add missing ERX*_EL1 registers Ruidong Tian
2024-01-10 7:57 ` Ruidong Tian
2024-01-10 12:20 ` Marc Zyngier
2024-01-10 12:20 ` Marc Zyngier
2024-01-15 14:47 ` Oliver Upton
2024-01-15 14:47 ` Oliver Upton
2024-01-15 17:21 ` James Morse
2024-01-15 17:21 ` James Morse
2024-01-16 15:38 ` Oliver Upton [this message]
2024-01-16 15:38 ` 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=ZaajAQafAnOgB8ho@linux.dev \
--to=oliver.upton@linux.dev \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=tianruidong@linux.alibaba.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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.