All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oupton@google.com>
To: Mark Rutland <mark.rutland@arm.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 13:09:28 +0000	[thread overview]
Message-ID: <YbnpCFBPNgmkEXjf@google.com> (raw)
In-Reply-To: <YbnUDny3GSNpyabJ@FVFF77S0Q05N>

Hi Mark,

On Wed, Dec 15, 2021 at 11:39:58AM +0000, Mark Rutland wrote:
> 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.

Agreed, I like your suggested changelog better :-)

> With that:
> 
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>

Thanks!

--
Best,
Oliver
_______________________________________________
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: Oliver Upton <oupton@google.com>
To: Mark Rutland <mark.rutland@arm.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 13:09:28 +0000	[thread overview]
Message-ID: <YbnpCFBPNgmkEXjf@google.com> (raw)
In-Reply-To: <YbnUDny3GSNpyabJ@FVFF77S0Q05N>

Hi Mark,

On Wed, Dec 15, 2021 at 11:39:58AM +0000, Mark Rutland wrote:
> 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.

Agreed, I like your suggested changelog better :-)

> With that:
> 
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>

Thanks!

--
Best,
Oliver

_______________________________________________
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: Oliver Upton <oupton@google.com>
To: Mark Rutland <mark.rutland@arm.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 13:09:28 +0000	[thread overview]
Message-ID: <YbnpCFBPNgmkEXjf@google.com> (raw)
In-Reply-To: <YbnUDny3GSNpyabJ@FVFF77S0Q05N>

Hi Mark,

On Wed, Dec 15, 2021 at 11:39:58AM +0000, Mark Rutland wrote:
> 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.

Agreed, I like your suggested changelog better :-)

> With that:
> 
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>

Thanks!

--
Best,
Oliver

  reply	other threads:[~2021-12-15 13:09 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
2021-12-15 11:39     ` Mark Rutland
2021-12-15 11:39     ` Mark Rutland
2021-12-15 13:09     ` Oliver Upton [this message]
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=YbnpCFBPNgmkEXjf@google.com \
    --to=oupton@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --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.