From: Mark Rutland <mark.rutland@arm.com>
To: Oliver Upton <oupton@google.com>
Cc: linux-arm-kernel@lists.infradead.org,
Marc Zyngier <maz@kernel.org>, Peter Shier <pshier@google.com>,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Subject: Re: [PATCH v4 1/6] KVM: arm64: Correctly treat writes to OSLSR_EL1 as undefined
Date: Wed, 15 Dec 2021 11:39:58 +0000 [thread overview]
Message-ID: <YbnUDny3GSNpyabJ@FVFF77S0Q05N> (raw)
In-Reply-To: <20211214172812.2894560-2-oupton@google.com>
Hi Oliver,
On Tue, Dec 14, 2021 at 05:28:07PM +0000, Oliver Upton wrote:
> Any valid implementation of the architecture should generate an
> undefined exception for writes to a read-only register, such as
> OSLSR_EL1. Nonetheless, the KVM handler actually implements write-ignore
> behavior.
>
> Align the trap handler for OSLSR_EL1 with hardware behavior. If such a
> write ever traps to EL2, inject an undef into the guest and print a
> warning.
I think this can still be read amibguously, since we don't explicitly state
that writes to OSLSR_EL1 should never trap (and the implications of being
UNDEFINED are subtle). How about:
| Writes to OSLSR_EL1 are UNDEFINED and should never trap from EL1 to EL2, but
| the KVM trap handler for OSLSR_EL1 handlees writes via ignore_write(). This
| is confusing to readers of the code, but shouldn't have any functional impact.
|
| For clarity, use write_to_read_only() rather than ignore_write(). If a trap
| is unexpectedly taken to EL2 in violation of the architecture, this will
| WARN_ONCE() and inject an undef into the guest.
With that:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> Reviewed-by: Reiji Watanabe <reijiw@google.com>
> Signed-off-by: Oliver Upton <oupton@google.com>
> ---
> arch/arm64/kvm/sys_regs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index e3ec1a44f94d..11b4212c2036 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -292,7 +292,7 @@ static bool trap_oslsr_el1(struct kvm_vcpu *vcpu,
> const struct sys_reg_desc *r)
> {
> if (p->is_write) {
> - return ignore_write(vcpu, p);
> + return write_to_read_only(vcpu, p, r);
> } else {
> p->regval = (1 << 3);
> return true;
> --
> 2.34.1.173.g76aa8bc2d0-goog
>
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Oliver Upton <oupton@google.com>
Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
Marc Zyngier <maz@kernel.org>, Peter Shier <pshier@google.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 1/6] KVM: arm64: Correctly treat writes to OSLSR_EL1 as undefined
Date: Wed, 15 Dec 2021 11:39:58 +0000 [thread overview]
Message-ID: <YbnUDny3GSNpyabJ@FVFF77S0Q05N> (raw)
In-Reply-To: <20211214172812.2894560-2-oupton@google.com>
Hi Oliver,
On Tue, Dec 14, 2021 at 05:28:07PM +0000, Oliver Upton wrote:
> Any valid implementation of the architecture should generate an
> undefined exception for writes to a read-only register, such as
> OSLSR_EL1. Nonetheless, the KVM handler actually implements write-ignore
> behavior.
>
> Align the trap handler for OSLSR_EL1 with hardware behavior. If such a
> write ever traps to EL2, inject an undef into the guest and print a
> warning.
I think this can still be read amibguously, since we don't explicitly state
that writes to OSLSR_EL1 should never trap (and the implications of being
UNDEFINED are subtle). How about:
| Writes to OSLSR_EL1 are UNDEFINED and should never trap from EL1 to EL2, but
| the KVM trap handler for OSLSR_EL1 handlees writes via ignore_write(). This
| is confusing to readers of the code, but shouldn't have any functional impact.
|
| For clarity, use write_to_read_only() rather than ignore_write(). If a trap
| is unexpectedly taken to EL2 in violation of the architecture, this will
| WARN_ONCE() and inject an undef into the guest.
With that:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> Reviewed-by: Reiji Watanabe <reijiw@google.com>
> Signed-off-by: Oliver Upton <oupton@google.com>
> ---
> arch/arm64/kvm/sys_regs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index e3ec1a44f94d..11b4212c2036 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -292,7 +292,7 @@ static bool trap_oslsr_el1(struct kvm_vcpu *vcpu,
> const struct sys_reg_desc *r)
> {
> if (p->is_write) {
> - return ignore_write(vcpu, p);
> + return write_to_read_only(vcpu, p, r);
> } else {
> p->regval = (1 << 3);
> return true;
> --
> 2.34.1.173.g76aa8bc2d0-goog
>
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Oliver Upton <oupton@google.com>
Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
Marc Zyngier <maz@kernel.org>, Peter Shier <pshier@google.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 1/6] KVM: arm64: Correctly treat writes to OSLSR_EL1 as undefined
Date: Wed, 15 Dec 2021 11:39:58 +0000 [thread overview]
Message-ID: <YbnUDny3GSNpyabJ@FVFF77S0Q05N> (raw)
In-Reply-To: <20211214172812.2894560-2-oupton@google.com>
Hi Oliver,
On Tue, Dec 14, 2021 at 05:28:07PM +0000, Oliver Upton wrote:
> Any valid implementation of the architecture should generate an
> undefined exception for writes to a read-only register, such as
> OSLSR_EL1. Nonetheless, the KVM handler actually implements write-ignore
> behavior.
>
> Align the trap handler for OSLSR_EL1 with hardware behavior. If such a
> write ever traps to EL2, inject an undef into the guest and print a
> warning.
I think this can still be read amibguously, since we don't explicitly state
that writes to OSLSR_EL1 should never trap (and the implications of being
UNDEFINED are subtle). How about:
| Writes to OSLSR_EL1 are UNDEFINED and should never trap from EL1 to EL2, but
| the KVM trap handler for OSLSR_EL1 handlees writes via ignore_write(). This
| is confusing to readers of the code, but shouldn't have any functional impact.
|
| For clarity, use write_to_read_only() rather than ignore_write(). If a trap
| is unexpectedly taken to EL2 in violation of the architecture, this will
| WARN_ONCE() and inject an undef into the guest.
With that:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> Reviewed-by: Reiji Watanabe <reijiw@google.com>
> Signed-off-by: Oliver Upton <oupton@google.com>
> ---
> arch/arm64/kvm/sys_regs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index e3ec1a44f94d..11b4212c2036 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -292,7 +292,7 @@ static bool trap_oslsr_el1(struct kvm_vcpu *vcpu,
> const struct sys_reg_desc *r)
> {
> if (p->is_write) {
> - return ignore_write(vcpu, p);
> + return write_to_read_only(vcpu, p, r);
> } else {
> p->regval = (1 << 3);
> return true;
> --
> 2.34.1.173.g76aa8bc2d0-goog
>
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply other threads:[~2021-12-15 11:40 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-14 17:28 [PATCH v4 0/6] KVM: arm64: Emulate the OS Lock Oliver Upton
2021-12-14 17:28 ` Oliver Upton
2021-12-14 17:28 ` Oliver Upton
2021-12-14 17:28 ` [PATCH v4 1/6] KVM: arm64: Correctly treat writes to OSLSR_EL1 as undefined Oliver Upton
2021-12-14 17:28 ` Oliver Upton
2021-12-14 17:28 ` Oliver Upton
2021-12-15 11:39 ` Mark Rutland [this message]
2021-12-15 11:39 ` Mark Rutland
2021-12-15 11:39 ` Mark Rutland
2021-12-15 13:09 ` Oliver Upton
2021-12-15 13:09 ` Oliver Upton
2021-12-15 13:09 ` Oliver Upton
2021-12-15 14:32 ` Mark Rutland
2021-12-15 14:32 ` Mark Rutland
2021-12-15 14:32 ` Mark Rutland
2021-12-14 17:28 ` [PATCH v4 2/6] KVM: arm64: Stash OSLSR_EL1 in the cpu context Oliver Upton
2021-12-14 17:28 ` Oliver Upton
2021-12-14 17:28 ` Oliver Upton
2021-12-15 11:57 ` Mark Rutland
2021-12-15 11:57 ` Mark Rutland
2021-12-15 11:57 ` Mark Rutland
2021-12-14 17:28 ` [PATCH v4 3/6] KVM: arm64: Allow guest to set the OSLK bit Oliver Upton
2021-12-14 17:28 ` Oliver Upton
2021-12-14 17:28 ` Oliver Upton
2021-12-15 12:15 ` Mark Rutland
2021-12-15 12:15 ` Mark Rutland
2021-12-15 12:15 ` Mark Rutland
2022-02-03 17:37 ` Oliver Upton
2022-02-03 17:37 ` Oliver Upton
2022-02-03 17:37 ` Oliver Upton
2021-12-14 17:28 ` [PATCH v4 4/6] KVM: arm64: Emulate the OS Lock Oliver Upton
2021-12-14 17:28 ` Oliver Upton
2021-12-14 17:28 ` Oliver Upton
2021-12-14 17:28 ` [PATCH v4 5/6] selftests: KVM: Add OSLSR_EL1 to the list of blessed regs Oliver Upton
2021-12-14 17:28 ` Oliver Upton
2021-12-14 17:28 ` Oliver Upton
2021-12-14 17:28 ` [PATCH v4 6/6] selftests: KVM: Test OS lock behavior Oliver Upton
2021-12-14 17:28 ` Oliver Upton
2021-12-14 17:28 ` 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=YbnUDny3GSNpyabJ@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oupton@google.com \
--cc=pshier@google.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.