linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Alexandru Elisei <alexandru.elisei@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>,
	Will Deacon <will@kernel.org>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: KVM/arm64: SPE: Translate VA to IPA on a stage 2 fault instead of pinning VM memory
Date: Wed, 27 Jul 2022 11:44:15 +0100	[thread overview]
Message-ID: <YuEW/zEjnddcRFad@monolith.localdoman> (raw)
In-Reply-To: <04dea801e298374fb783bf0760b15241@kernel.org>

On Wed, Jul 27, 2022 at 11:29:03AM +0100, Marc Zyngier wrote:
> On 2022-07-27 11:19, Alexandru Elisei wrote:
> > Hi Oliver,
> > 
> > Thank you for the help, replies below.
> > 
> > On Tue, Jul 26, 2022 at 10:51:21AM -0700, Oliver Upton wrote:
> > > Hi Alex,
> > > 
> > > On Mon, Jul 25, 2022 at 11:06:24AM +0100, Alexandru Elisei wrote:
> > > 
> > > [...]
> > > 
> > > > > A funkier approach might be to defer pinning of the buffer until the SPE is
> > > > > enabled and avoid pinning all of VM memory that way, although I can't
> > > > > immediately tell how flexible the architecture is in allowing you to cache
> > > > > the base/limit values.
> > > >
> > > > I was investigating this approach, and Mark raised a concern that I think
> > > > might be a showstopper.
> > > >
> > > > Let's consider this scenario:
> > > >
> > > > Initial conditions: guest at EL1, profiling disabled (PMBLIMITR_EL1.E = 0,
> > > > PMBSR_EL1.S = 0, PMSCR_EL1.{E0SPE,E1SPE} = {0,0}).
> > > >
> > > > 1. Guest programs the buffer and enables it (PMBLIMITR_EL1.E = 1).
> > > > 2. Guest programs SPE to enable profiling at **EL0**
> > > > (PMSCR_EL1.{E0SPE,E1SPE} = {1,0}).
> > > > 3. Guest changes the translation table entries for the buffer. The
> > > > architecture allows this.
> > > > 4. Guest does an ERET to EL0, thus enabling profiling.
> > > >
> > > > Since KVM cannot trap the ERET to EL0, it will be impossible for KVM to pin
> > > > the buffer at stage 2 when profiling gets enabled at EL0.
> > > 
> > > Not saying we necessarily should, but this is possible with FGT no?
> > 
> > It doesn't look to me like FEAT_FGT offers any knobs to trap ERET from
> > EL1.
> 
> See HFGITR.ERET.

Ah, so that's the register, thanks!

I stil am not sure that having FEAT_SPE, an Armv8.3 extension, depend on
FEAT_FGT, an Armv8.6 extension, is the best idea. Do you know of any machines
that have FEAT_SPE and FEAT_FGT?

On the plus side, KVM could enable the trap only in the case above, and disable
it after the ERET is trapped, so it should be relatively cheap to use.

Thanks,
Alex

> 
> Thanks,
> 
>         M.
> -- 
> Jazz is not dead. It just smells funny...

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

  reply	other threads:[~2022-07-27 10:44 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-19 13:51 KVM/arm64: SPE: Translate VA to IPA on a stage 2 fault instead of pinning VM memory Alexandru Elisei
2022-04-19 14:10 ` Will Deacon
2022-04-19 14:44   ` Alexandru Elisei
2022-04-19 14:59     ` Will Deacon
2022-04-19 15:20       ` Alexandru Elisei
2022-04-19 15:35         ` Alexandru Elisei
2022-07-25 10:06   ` Alexandru Elisei
2022-07-26 17:51     ` Oliver Upton
2022-07-27  9:30       ` Marc Zyngier
2022-07-27  9:52         ` Marc Zyngier
2022-07-27 10:38           ` Alexandru Elisei
2022-07-27 16:06             ` Oliver Upton
2022-07-27 10:56         ` Alexandru Elisei
2022-07-27 11:18           ` Marc Zyngier
2022-07-27 12:10             ` Alexandru Elisei
2022-07-27 10:19       ` Alexandru Elisei
2022-07-27 10:29         ` Marc Zyngier
2022-07-27 10:44           ` Alexandru Elisei [this message]
2022-07-27 11:08             ` Marc Zyngier
2022-07-27 11:57               ` Alexandru Elisei
2022-07-27 15:15                 ` Oliver Upton
2022-07-27 11:00       ` Alexandru Elisei
2022-08-01 17:00     ` Will Deacon
2022-08-02  9:49       ` Alexandru Elisei
2022-08-02 19:34         ` Oliver Upton
2022-08-09 14:01           ` Alexandru Elisei
2022-08-09 18:43             ` Oliver Upton
2022-08-10  9:37               ` Alexandru Elisei
2022-08-10 15:25                 ` Oliver Upton
2022-08-12 13:05                   ` Alexandru Elisei
2022-08-17 15:05                     ` Oliver Upton
2022-09-12 14:50                       ` Alexandru Elisei
2022-09-13 10:58                         ` Oliver Upton
2022-09-13 12:41                           ` Alexandru Elisei
2022-09-13 14:13                             ` Oliver Upton
2023-01-03 14:26                               ` Alexandru Elisei

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=YuEW/zEjnddcRFad@monolith.localdoman \
    --to=alexandru.elisei@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --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).