All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH] arm64: Document requirements for fine grained traps at boot
Date: Mon, 29 Mar 2021 18:06:57 +0100	[thread overview]
Message-ID: <20210329170657.GH5166@sirena.org.uk> (raw)
In-Reply-To: <20210326115541.GC5126@arm.com>


[-- Attachment #1.1: Type: text/plain, Size: 1736 bytes --]

On Fri, Mar 26, 2021 at 11:55:41AM +0000, Catalin Marinas wrote:
> On Fri, Mar 12, 2021 at 03:49:17PM +0000, Mark Brown wrote:

> > +    - HAFGRTR_EL2, HDFGWTR_EL2, HDFGRTR_EL2, HFGWTR_EL2, HFGRTR_EL2 and
> > +      HFGITR_EL2 must be initialised to 0.

> While this requirement is correct, documenting such individual registers
> doesn't scales well. You may run a 5 year old kernel on a newer CPU and
> we can't predict which control registers have been added and what
> side-effect they have. The architecture, at least for the above

I'm not a huge fan of writing things this way either, I'd inferred that
this sort of minimal and specific thing was the idiom desired so was
trying to follow.

> Can we instead have a broad statement regarding any EL1/EL2 registers
> that they should be either rest to 0 or to the architectural (warm)
> reset value as per the ARM ARM? Or something like any feature must be
> disabled by default at the EL1/EL2 control registers level and this
> would imply the fine-grained traps.

> We currently have this statement:

>   All writable architected system registers at the exception level where
>   the kernel image will be entered must be initialised by software at a
>   higher exception level to prevent execution in an UNKNOWN state.

> The "prevent execution in an UNKNOWN state" needs to be clearer. The
> above should also include exception levels _below_ the one where the
> kernel is entered. It doesn't help if KVM is old and has no clue of new
> EL1-specific registers.

Right, I think both those things are needed to cover the general case.
The exception levels bit is hopefully straightforward but wording for
the clarification bit is more tricky - I'll try to come up with
something.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

      parent reply	other threads:[~2021-03-29 23:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-12 15:49 [PATCH] arm64: Document requirements for fine grained traps at boot Mark Brown
2021-03-26 11:55 ` Catalin Marinas
2021-03-29 10:31   ` Will Deacon
2021-03-29 12:16     ` Catalin Marinas
2021-03-29 12:25     ` Mark Brown
2021-03-29 17:06   ` Mark Brown [this message]

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=20210329170657.GH5166@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.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 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.