[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200513104850.6rer4ued2uq6lpxs@dbrazdil-macbookpro.roam.corp.google.com>
Date: Wed, 13 May 2020 11:48:50 +0100
From: David Brazdil <dbrazdil@...gle.com>
To: Marc Zyngier <maz@...nel.org>
Cc: Quentin Perret <qperret@...gle.com>,
David Brazdil <dbrazdil@...gle.com>,
Catalin Marinas <catalin.marinas@....com>,
James Morse <james.morse@....com>,
Julien Thierry <julien.thierry.kdev@...il.com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Will Deacon <will@...nel.org>, kvmarm@...ts.cs.columbia.edu,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/15] arm64: kvm: Formalize host-hyp hypcall ABI
> > In fact David already has a nice patch that transforms the whole thing
> > in a jump table, which is much nicer. I'll let him share the details
> > :)
>
> Ah! Looking forward to reviewing it then!
It's not actually that different. It still has the same header file, just uses
the macros to generate a jump table rather than an array of function pointers.
The main advantage being that we can avoid .hyp.text dependency on
physvirt_offset. Feel free to have a look, branch 'topic/el2-obj-wip' at:
https://android-kvm.googlesource.com/linux
Perhaps this is not worth the trouble. We do hope to get to a point where the
ABI between .text and .hyp.text is formalized, but in my mind that ABI is
unlikely to be using this same hypcall path.
On the other hand, I've played with preserving the function-pointer interface
in the last couple of days and later in this series we do end up having to
declare all of the hcall entry points (which now have two ELF symbols), so we
end up with a similar table regardless, just with no IDs assigned.
-David
Powered by blists - more mailing lists