From: Julien Thierry <julien.thierry@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
linux-arch@vger.kernel.org, daniel.thompson@linaro.org,
Arnd Bergmann <arnd@arndb.de>,
marc.zyngier@arm.com, will.deacon@arm.com,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
christoffer.dall@arm.com, james.morse@arm.com,
joel@joelfernandes.org
Subject: Re: [PATCH v8 01/26] arm64: Fix HCR.TGE status for NMI contexts
Date: Mon, 14 Jan 2019 16:12:39 +0000 [thread overview]
Message-ID: <229aade3-5bb3-aad4-bd9a-d6220db836c0@arm.com> (raw)
In-Reply-To: <20190114155634.GB84430@arrakis.emea.arm.com>
On 14/01/2019 15:56, Catalin Marinas wrote:
> On Tue, Jan 08, 2019 at 02:07:19PM +0000, Julien Thierry wrote:
>> When using VHE, the host needs to clear HCR_EL2.TGE bit in order
>> to interract with guest TLBs, switching from EL2&0 translation regime
>> to EL1&0.
>>
>> However, some non-maskable asynchronous event could happen while TGE is
>> cleared like SDEI. Because of this address translation operations
>> relying on EL2&0 translation regime could fail (tlb invalidation,
>> userspace access, ...).
>
> Why would an NMI context need to access user space? (just curious what
> breaks exactly without this patch; otherwise it looks fine)
If I remember correctly, the SDEI interrupt might perform cache
maintenance with EL2&0 translation regime, but James can probably give
more detail (or correct me if I'm wrong).
Otherwise, if we decide to use the pseudo NMI for profiling with perf, I
believe the perf interrupt can access user space (although I'm not
completely sure whether that might be to record profiling data in
buffers shared with user space or something else).
Thanks,
--
Julien Thierry
next prev parent reply other threads:[~2019-01-14 16:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1546956464-48825-1-git-send-email-julien.thierry@arm.com>
2019-01-08 14:07 ` [PATCH v8 01/26] arm64: Fix HCR.TGE status for NMI contexts Julien Thierry
2019-01-08 14:07 ` Julien Thierry
2019-01-14 15:56 ` Catalin Marinas
2019-01-14 15:56 ` Catalin Marinas
2019-01-14 16:12 ` Julien Thierry [this message]
2019-01-14 16:12 ` Julien Thierry
2019-01-14 17:25 ` James Morse
2019-01-14 17:25 ` James Morse
2019-01-16 13:35 ` Sasha Levin
2019-01-28 9:16 ` Marc Zyngier
2019-01-28 9:16 ` 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=229aade3-5bb3-aad4-bd9a-d6220db836c0@arm.com \
--to=julien.thierry@arm.com \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@arm.com \
--cc=daniel.thompson@linaro.org \
--cc=james.morse@arm.com \
--cc=joel@joelfernandes.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=stable@vger.kernel.org \
--cc=will.deacon@arm.com \
/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).