On 2020-02-11 09:55, Will Deacon wrote:

On Tue, Feb 11, 2020 at 09:14:52AM +0000, Marc Zyngier wrote:

quoted

On 2020-02-10 18:07, Will Deacon wrote:

quoted

On Mon, Feb 10, 2020 at 06:03:28PM +0000, Mark Rutland wrote:

quoted

On Mon, Feb 10, 2020 at 05:52:15PM +0000, Will Deacon wrote:

quoted

On Mon, Feb 10, 2020 at 05:18:58PM +0000, James Morse wrote:

quoted

On 28/01/2020 18:49, Sami Tolvanen wrote:

quoted

Filter out CC_FLAGS_SCS and -ffixed-x18 for code that runs at a
different exception level.

Hmmm, there are two things being disabled here.

Stashing the lr in memory pointed to by VA won't work transparently at EL2 ... but
shouldn't KVM's C code still treat x18 as a fixed register?

My review of v6 suggested dropping the -ffixed-x18 as well, since it's only
introduced by SCS (in patch 5) and so isn't required by anything else. Why
do you think it's needed?

When EL1 code calls up to hyp, it expects x18 to be preserved across
the
call, so hyp needs to either preserve it explicitly across a
transitions
from/to EL1 or always preserve it.

I thought we explicitly saved/restored it across the call after
af12376814a5 ("arm64: kvm: stop treating register x18 as caller save").
Is
that not sufficient?

quoted

The latter is easiest since any code used by VHE hyp code will need
x18
saved anyway (ans so any common hyp code needs to).

I would personally prefer to split the VHE and non-VHE code so they can
be
compiled with separate options.

This is going to generate a lot of code duplication (or at least 
object
duplication),
as the two code paths are intricately linked and splitting them to 
support
different
compilation options and/or calling conventions.

I'm not fundamentally opposed to that, but it should come with ways to 
still
manage it as a unified code base as much as possible, as ways to 
discard the
unused part at runtime (which should become easy to do once we have 
two
distinct sets of objects).

Agreed, and I don't want to hold up the SCS patches because of this. 
I'm
just nervous about the function attribute because I've only ever had
terrible experiences with them. Maybe it will work this time (!)

I have the same experience chasing missing __hyp_text attributes. Until 
we
have tooling that picks on this *at compile time*, we'll have to play
wack-a-mole with them...

         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