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:38:53 +0100 [thread overview]
Message-ID: <YuEVq8Au7YsDLOdI@monolith.localdoman> (raw)
In-Reply-To: <874jz2yja5.wl-maz@kernel.org>
Hi Marc,
On Wed, Jul 27, 2022 at 10:52:34AM +0100, Marc Zyngier wrote:
> On Wed, 27 Jul 2022 10:30:59 +0100,
> Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Tue, 26 Jul 2022 18:51:21 +0100,
> > Oliver Upton <oliver.upton@linux.dev> wrote:
> > >
> > > Doesn't pinning the buffer also imply pinning the stage 1 tables
> > > responsible for its translation as well? I agree that pinning the buffer
> > > is likely the best way forward as pinning the whole of guest memory is
> > > entirely impractical.
>
> Huh, I just realised that you were talking about S1. I don't think we
> need to do this. As long as the translation falls into a mapped
> region (pinned or not), we don't need to worry.
>
> If we get a S2 translation fault from SPE, we just go and map it. And
> TBH the pinning here is just a optimisation against things like swap,
> KSM and similar things. The only thing we need to make sure is that
> the fault is handled in the context of the vcpu that owns this SPU.
>
> Alex, can you think of anything that would cause a problem (other than
> performance and possible blackout windows) if we didn't do any pinning
> at all and just handled the SPE interrupts as normal page faults?
PMBSR_EL1.DL might be set 1 as a result of stage 2 fault reported by SPE,
which means the last record written is incomplete. Records have a variable
size, so it's impossible for KVM to revert to the end of the last known
good record without parsing the buffer (references here [1]). And even if
KVM would know the size of a record, there's this bit in the Arm ARM which
worries me (ARM DDI 0487H.a, page D10-5177):
"The architecture does not require that a sample record is written
sequentially by the SPU, only that:
[..]
- On a Profiling Buffer management interrupt, PMBSR_EL1.DL indicates
whether PMBPTR_EL1 points to the first byte after the last complete
sample record."
So there might be gaps in the buffer, meaning that the entire buffer would
have to be discarded if DL is set as a result of a stage 2 fault.
Also, I'm not sure if you're aware of this, but SPE reports the guest VA in
PMBPTR_EL1 (not the IPA) on a fault, so KVM would have to walk the guest's
stage 1 tables to service the faults, which would add to the overhead of
servicing the fault. Don't know if that makes a difference, just thought I
should mention it as another peculiarity of SPE.
[1] https://lore.kernel.org/all/Yl7KewpTj+7NSonf@monolith.localdoman/
Thanks,
Alex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-07-27 10:39 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 [this message]
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
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=YuEVq8Au7YsDLOdI@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