On Fri, 27 Mar 2015 00:14:12 +
Andre Przywara andre.przyw...@arm.com wrote:
On 03/26/2015 10:06 PM, Marc Zyngier wrote:
On Thu, 26 Mar 2015 14:39:37 +
Andre Przywara andre.przyw...@arm.com wrote:
Using the framework provided by the recent vgic.c changes, we
register a
The current alternative instruction framework is not kind to branches,
potentially leading to all kind of hacks in the code that uses
alternatives. This series expands it to deal with immediate branches
(for a start), and applies it to the VGIC world switch.
Patch #1 adds the required
Add a new item to the feature set (ARM64_HAS_SYSREG_GIC_CPUIF)
to indicate that we have a system register GIC CPU interface
This will help KVM switching to alternative instruction patching.
Reviewed-by: Andre Przywara andre.przyw...@arm.com
Acked-by: Will Deacon will.dea...@arm.com
Since all immediate branches are PC-relative on Aarch64, these
instructions cannot be used as an alternative with the simplistic
approach we currently have (the immediate has been computed from
the .altinstr_replacement section, and end-up being completely off
if we insert it directly).
This
As we detect more architectural features at runtime, it makes
sense to reuse the existing framework whilst avoiding to call
a feature an erratum...
This patch extract the core capability parsing, moves it into
a new file (cpufeature.c), and let the CPU errata detection code
use it.
Reviewed-by:
On Thu, Mar 26, 2015 at 02:39:37PM +, Andre Przywara wrote:
Using the framework provided by the recent vgic.c changes, we
register a kvm_io_bus device on mapping the virtual GICv3 resources.
The distributor mapping is pretty straight forward, but the
redistributors need some more love,
On Thu, Mar 26, 2015 at 02:39:35PM +, Andre Przywara wrote:
Using the framework provided by the recent vgic.c changes we register
a kvm_io_bus device when initializing the virtual GICv2.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
Reviewed-by: Christoffer Dall
On Thu, Mar 26, 2015 at 02:39:36PM +, Andre Przywara wrote:
Currently we handle the redistributor registers in two separate MMIO
regions, one for the overall behaviour and SPIs and one for the
SGIs/PPIs. That latter forces the creation of _two_ KVM I/O bus
devices for each redistributor.
On Thu, Mar 26, 2015 at 02:39:34PM +, Andre Przywara wrote:
Currently we use a lot of VGIC specific code to do the MMIO
dispatching.
Use the previous reworks to add kvm_io_bus style MMIO handlers.
Those are not yet called by the MMIO abort handler, also the actual
VGIC emulator function
On Thu, Mar 26, 2015 at 02:39:38PM +, Andre Przywara wrote:
Currently we have struct kvm_exit_mmio for encapsulating MMIO abort
data to be passed on from syndrome decoding all the way down to the
VGIC register handlers. Now as we switch the MMIO handling to be
routed through the KVM MMIO
Our in-kernel VGIC emulation still uses struct kvm_run briefly before
writing back the emulation result into the guest register. Using a
userspace mapped data structure within the kernel sounds dodgy, also
we do some extra copying at the moment at the end of the VGIC
emulation code.
Replace the
11 matches
Mail list logo
