All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: kvm@vger.kernel.org, will@kernel.org,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 5/6] KVM: arm64: Treat 32bit ID registers as RAZ/WI on 64bit-only system
Date: Tue, 23 Aug 2022 12:27:34 -0500	[thread overview]
Message-ID: <YwUOBuDTzw+zT0/T@google.com> (raw)
In-Reply-To: <87czcqx547.wl-maz@kernel.org>

Hey Marc,

Thanks for the review!

On Tue, Aug 23, 2022 at 06:05:28PM +0100, Marc Zyngier wrote:
> On Wed, 17 Aug 2022 22:48:17 +0100,
> Oliver Upton <oliver.upton@linux.dev> wrote:
> > 
> > One of the oddities of the architecture is that the AArch64 views of the
> > AArch32 ID registers are UNKNOWN if AArch32 isn't implemented at any EL.
> > Nonetheless, KVM exposes these registers to userspace for the sake of
> > save/restore. It is possible that the UNKNOWN value could differ between
> > systems, leading to a rejected write from userspace.
> > 
> > Avoid the issue altogether by handling the AArch32 ID registers as
> > RAZ/WI when on an AArch64-only system.
> > 
> > Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
> > ---
> >  arch/arm64/kvm/sys_regs.c | 63 ++++++++++++++++++++++++++-------------
> >  1 file changed, 43 insertions(+), 20 deletions(-)
> > 
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index 9f06c85f26b8..5f6a633182c8 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -1145,6 +1145,20 @@ static unsigned int id_visibility(const struct kvm_vcpu *vcpu,
> >  	return 0;
> >  }
> >  
> > +static unsigned int aa32_id_visibility(const struct kvm_vcpu *vcpu,
> > +				       const struct sys_reg_desc *r)
> > +{
> > +	/*
> > +	 * AArch32 ID registers are UNKNOWN if AArch32 isn't implemented at any
> > +	 * EL. Promote to RAZ/WI in order to guarantee consistency between
> > +	 * systems.
> > +	 */
> > +	if (!kvm_supports_32bit_el0())
> > +		return REG_RAZ | REG_USER_WI;
> 
> This is probably only a nit, but why does one visibility has a _USER_
> tag while the other doesn't? In other word, what sysregs are WI from
> userspace that aren't so from the guest?
> 
> Also, do we have any cases where RAZ and WI would be used
> independently? My gut feeling is that RAZ implies WI in most (all?)
> cases. If this assumption holds, shouldn't we simply rename REG_RAZ to
> REG_RAZ_WI and be done with it?

Yeah, this reads a bit strange, but there is some reason around it (I
think!)

As it applies to ID registers, REG_RAZ already implies RAZ w/ immutable
writes (-EINVAL if something different is written). As such I didn't want
to change the meaning of the other ID registers to WI and only ignore
writes for the registers that could have an UNKNOWN value. Furthermore,
I added the _USER_ tag to make it clear that we aren't magically allowing
writes from the guest to these registers.

I think we will need an additional visibility bit (or special accessor,
which I tried to avoid) to precisely apply WI to the 32bit registers,
but if the _USER_ tag is distracting I can get rid of it. After all,
hardware should politely UNDEF the guest when writing to such a
register.

Thoughts?

--
Thanks,
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 <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, james.morse@arm.com,
	alexandru.elisei@arm.com, suzuki.poulose@arm.com,
	will@kernel.org
Subject: Re: [PATCH 5/6] KVM: arm64: Treat 32bit ID registers as RAZ/WI on 64bit-only system
Date: Tue, 23 Aug 2022 12:27:34 -0500	[thread overview]
Message-ID: <YwUOBuDTzw+zT0/T@google.com> (raw)
In-Reply-To: <87czcqx547.wl-maz@kernel.org>

Hey Marc,

Thanks for the review!

On Tue, Aug 23, 2022 at 06:05:28PM +0100, Marc Zyngier wrote:
> On Wed, 17 Aug 2022 22:48:17 +0100,
> Oliver Upton <oliver.upton@linux.dev> wrote:
> > 
> > One of the oddities of the architecture is that the AArch64 views of the
> > AArch32 ID registers are UNKNOWN if AArch32 isn't implemented at any EL.
> > Nonetheless, KVM exposes these registers to userspace for the sake of
> > save/restore. It is possible that the UNKNOWN value could differ between
> > systems, leading to a rejected write from userspace.
> > 
> > Avoid the issue altogether by handling the AArch32 ID registers as
> > RAZ/WI when on an AArch64-only system.
> > 
> > Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
> > ---
> >  arch/arm64/kvm/sys_regs.c | 63 ++++++++++++++++++++++++++-------------
> >  1 file changed, 43 insertions(+), 20 deletions(-)
> > 
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index 9f06c85f26b8..5f6a633182c8 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -1145,6 +1145,20 @@ static unsigned int id_visibility(const struct kvm_vcpu *vcpu,
> >  	return 0;
> >  }
> >  
> > +static unsigned int aa32_id_visibility(const struct kvm_vcpu *vcpu,
> > +				       const struct sys_reg_desc *r)
> > +{
> > +	/*
> > +	 * AArch32 ID registers are UNKNOWN if AArch32 isn't implemented at any
> > +	 * EL. Promote to RAZ/WI in order to guarantee consistency between
> > +	 * systems.
> > +	 */
> > +	if (!kvm_supports_32bit_el0())
> > +		return REG_RAZ | REG_USER_WI;
> 
> This is probably only a nit, but why does one visibility has a _USER_
> tag while the other doesn't? In other word, what sysregs are WI from
> userspace that aren't so from the guest?
> 
> Also, do we have any cases where RAZ and WI would be used
> independently? My gut feeling is that RAZ implies WI in most (all?)
> cases. If this assumption holds, shouldn't we simply rename REG_RAZ to
> REG_RAZ_WI and be done with it?

Yeah, this reads a bit strange, but there is some reason around it (I
think!)

As it applies to ID registers, REG_RAZ already implies RAZ w/ immutable
writes (-EINVAL if something different is written). As such I didn't want
to change the meaning of the other ID registers to WI and only ignore
writes for the registers that could have an UNKNOWN value. Furthermore,
I added the _USER_ tag to make it clear that we aren't magically allowing
writes from the guest to these registers.

I think we will need an additional visibility bit (or special accessor,
which I tried to avoid) to precisely apply WI to the 32bit registers,
but if the _USER_ tag is distracting I can get rid of it. After all,
hardware should politely UNDEF the guest when writing to such a
register.

Thoughts?

--
Thanks,
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 <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, james.morse@arm.com,
	alexandru.elisei@arm.com, suzuki.poulose@arm.com,
	will@kernel.org
Subject: Re: [PATCH 5/6] KVM: arm64: Treat 32bit ID registers as RAZ/WI on 64bit-only system
Date: Tue, 23 Aug 2022 12:27:34 -0500	[thread overview]
Message-ID: <YwUOBuDTzw+zT0/T@google.com> (raw)
In-Reply-To: <87czcqx547.wl-maz@kernel.org>

Hey Marc,

Thanks for the review!

On Tue, Aug 23, 2022 at 06:05:28PM +0100, Marc Zyngier wrote:
> On Wed, 17 Aug 2022 22:48:17 +0100,
> Oliver Upton <oliver.upton@linux.dev> wrote:
> > 
> > One of the oddities of the architecture is that the AArch64 views of the
> > AArch32 ID registers are UNKNOWN if AArch32 isn't implemented at any EL.
> > Nonetheless, KVM exposes these registers to userspace for the sake of
> > save/restore. It is possible that the UNKNOWN value could differ between
> > systems, leading to a rejected write from userspace.
> > 
> > Avoid the issue altogether by handling the AArch32 ID registers as
> > RAZ/WI when on an AArch64-only system.
> > 
> > Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
> > ---
> >  arch/arm64/kvm/sys_regs.c | 63 ++++++++++++++++++++++++++-------------
> >  1 file changed, 43 insertions(+), 20 deletions(-)
> > 
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index 9f06c85f26b8..5f6a633182c8 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -1145,6 +1145,20 @@ static unsigned int id_visibility(const struct kvm_vcpu *vcpu,
> >  	return 0;
> >  }
> >  
> > +static unsigned int aa32_id_visibility(const struct kvm_vcpu *vcpu,
> > +				       const struct sys_reg_desc *r)
> > +{
> > +	/*
> > +	 * AArch32 ID registers are UNKNOWN if AArch32 isn't implemented at any
> > +	 * EL. Promote to RAZ/WI in order to guarantee consistency between
> > +	 * systems.
> > +	 */
> > +	if (!kvm_supports_32bit_el0())
> > +		return REG_RAZ | REG_USER_WI;
> 
> This is probably only a nit, but why does one visibility has a _USER_
> tag while the other doesn't? In other word, what sysregs are WI from
> userspace that aren't so from the guest?
> 
> Also, do we have any cases where RAZ and WI would be used
> independently? My gut feeling is that RAZ implies WI in most (all?)
> cases. If this assumption holds, shouldn't we simply rename REG_RAZ to
> REG_RAZ_WI and be done with it?

Yeah, this reads a bit strange, but there is some reason around it (I
think!)

As it applies to ID registers, REG_RAZ already implies RAZ w/ immutable
writes (-EINVAL if something different is written). As such I didn't want
to change the meaning of the other ID registers to WI and only ignore
writes for the registers that could have an UNKNOWN value. Furthermore,
I added the _USER_ tag to make it clear that we aren't magically allowing
writes from the guest to these registers.

I think we will need an additional visibility bit (or special accessor,
which I tried to avoid) to precisely apply WI to the 32bit registers,
but if the _USER_ tag is distracting I can get rid of it. After all,
hardware should politely UNDEF the guest when writing to such a
register.

Thoughts?

--
Thanks,
Oliver

  reply	other threads:[~2022-08-23 17:27 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-17 21:48 [PATCH 0/6] KVM: arm64: Treat 32bit ID registers as RAZ/WI on 64bit-only system Oliver Upton
2022-08-17 21:48 ` Oliver Upton
2022-08-17 21:48 ` Oliver Upton
2022-08-17 21:48 ` [PATCH 1/6] KVM: arm64: Use visibility hook to treat ID regs as RAZ Oliver Upton
2022-08-17 21:48   ` Oliver Upton
2022-08-17 21:48   ` Oliver Upton
2022-08-30  4:54   ` Reiji Watanabe
2022-08-30  4:54     ` Reiji Watanabe
2022-08-30  4:54     ` Reiji Watanabe
2022-08-17 21:48 ` [PATCH 2/6] KVM: arm64: Remove internal accessor helpers for id regs Oliver Upton
2022-08-17 21:48   ` Oliver Upton
2022-08-17 21:48   ` Oliver Upton
2022-08-30  5:45   ` Reiji Watanabe
2022-08-30  5:45     ` Reiji Watanabe
2022-08-30  5:45     ` Reiji Watanabe
2022-08-30 17:45     ` Oliver Upton
2022-08-30 17:45       ` Oliver Upton
2022-08-30 17:45       ` Oliver Upton
2022-08-17 21:48 ` [PATCH 3/6] KVM: arm64: Spin off helper for calling visibility hook Oliver Upton
2022-08-17 21:48   ` Oliver Upton
2022-08-17 21:48   ` Oliver Upton
2022-08-30  6:01   ` Reiji Watanabe
2022-08-30  6:01     ` Reiji Watanabe
2022-08-30  6:01     ` Reiji Watanabe
2022-08-17 21:48 ` [PATCH 4/6] KVM: arm64: Add a visibility bit to ignore user writes Oliver Upton
2022-08-17 21:48   ` Oliver Upton
2022-08-17 21:48   ` Oliver Upton
2022-08-31  3:29   ` Reiji Watanabe
2022-08-31  3:29     ` Reiji Watanabe
2022-08-31  3:29     ` Reiji Watanabe
2022-08-31 14:42     ` Oliver Upton
2022-08-31 14:42       ` Oliver Upton
2022-08-31 14:42       ` Oliver Upton
2022-09-01  4:57       ` Reiji Watanabe
2022-09-01  4:57         ` Reiji Watanabe
2022-09-01  4:57         ` Reiji Watanabe
2022-08-17 21:48 ` [PATCH 5/6] KVM: arm64: Treat 32bit ID registers as RAZ/WI on 64bit-only system Oliver Upton
2022-08-17 21:48   ` Oliver Upton
2022-08-17 21:48   ` Oliver Upton
2022-08-23 17:05   ` Marc Zyngier
2022-08-23 17:05     ` Marc Zyngier
2022-08-23 17:05     ` Marc Zyngier
2022-08-23 17:27     ` Oliver Upton [this message]
2022-08-23 17:27       ` Oliver Upton
2022-08-23 17:27       ` Oliver Upton
2022-08-17 21:48 ` [PATCH 6/6] KVM: selftests: Add test for RAZ/WI AArch32 ID registers Oliver Upton
2022-08-17 21:48   ` Oliver Upton
2022-08-17 21:48   ` 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=YwUOBuDTzw+zT0/T@google.com \
    --to=oliver.upton@linux.dev \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=will@kernel.org \
    /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.