linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Alexandru Elisei <alexandru.elisei@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Will Deacon <will@kernel.org>,
	kernel-team@android.com, ascull@google.com, tabba@google.com,
	dbrazdil@google.com, James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>
Subject: Re: [PATCH] KVM: arm64: Clarify vcpu reset behaviour
Date: Wed, 07 Apr 2021 17:26:47 +0100	[thread overview]
Message-ID: <874kgioybc.wl-maz@kernel.org> (raw)
In-Reply-To: <40906aba-3d29-db38-f305-0c32603b34dd@arm.com>

On Wed, 07 Apr 2021 16:59:58 +0100,
Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> 
> Hi Marc,
> 
> On 4/6/21 1:58 PM, Marc Zyngier wrote:
> > Although the KVM_ARM_VCPU_INIT documentation mention that the
> > registers are reset to their "initial values", it doesn't
> > describe what these values are.
> >
> > Describe this state explicitly.
> 
> This is a good idea.

Yeah, it turns out this is something we need for pKVM, because the
reset state is slightly different.

> 
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> >  Documentation/virt/kvm/api.rst | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > index 38e327d4b479..e2237e4e10ba 100644
> > --- a/Documentation/virt/kvm/api.rst
> > +++ b/Documentation/virt/kvm/api.rst
> > @@ -3115,6 +3115,16 @@ optional features it should have.  This will cause a reset of the cpu
> >  registers to their initial values.  If this is not called, KVM_RUN will
> >  return ENOEXEC for that vcpu.
> >  
> > +The initial values are defined as:
> > +	- Processor state:
> > +		* AArch64: EL1h, D, A, I and F bits set
> 
> That value matches the macro VCPU_RESET_STATE_EL1.
> 
> > +		* Aarch32: SVC, D, A, I and F bits set
> VCPU_RESET_STATE_SVC doesn't have a D bit; according to ARM DDI 0487G.a, page
> G1-5965, CPSR doesn't have a D bit either (I might be reading it wrong).

Meh, copy paste. Thanks for that,

> > +	- General Purpose registers, including PC and SP: set to 0
> 
> They are zero'ed explicitly in kvm_reset_vcpu().
> 
> > +	- FPSIMD/NEON registers: set to 0
> 
> I haven't been able to find where they are initialized explicitly, I
> assume they aren't. They are zero because the kvm_vcpu struct is
> allocated via kmem_cache_zalloc() in kvm_vm_ioctl_create_vcpu(), so
> this is correct.

Indeed. However, this outlines an interesting buglet. Userspace is
allowed to call KVM_ARM_VCPU_INIT at any point, and get the vcpu back
to the reset state.

The lack of explicit wipeout of the FPSIMD file is on its own a bug
which crept in with e47c2055c6 ("KVM: arm64: Make struct kvm_regs
userspace-only"), when kvm_cpu_context started to use user_pt_regs
directly.

I'll fix that separately, thanks for pushing me to have a closer look.

> 
> > +	- SVE registers: set to 0
> 
> They are zero'ed explicitly in kvm_vcpu_reset_sve().
> 
> > +	- System registers: Reset to their architecturally defined
> > +	  values as for a warm reset to EL1 (resp. SVC)
> 
> This is done in kvm_reset_vcpu() -> kvm_reset_sys_regs(), which from
> what I can tell does the right thing, but I haven't checked each and
> every register.
> 
> Assuming the D bit for CPSR/SPSR was a typo and with it removed:
> 
> Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>

Thanks for that. I'll send the other fix separately.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-04-07 16:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-06 12:58 [PATCH] KVM: arm64: Clarify vcpu reset behaviour Marc Zyngier
2021-04-07 15:59 ` Alexandru Elisei
2021-04-07 16:26   ` Marc Zyngier [this message]
2021-04-07 20:35 ` Will Deacon
2021-04-08 10:36   ` Marc Zyngier
2021-04-08 10:53     ` Will Deacon
2021-04-08 13:14       ` 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=874kgioybc.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=alexandru.elisei@arm.com \
    --cc=ascull@google.com \
    --cc=dbrazdil@google.com \
    --cc=james.morse@arm.com \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).