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 usa
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 bus, it does not make sense anymore to
use that structure already from
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: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
Reviewed-by: Christoffer Dall
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 MMI
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 fun
In order to be useable by kvmtool, a macvtap interface requires
some minimal configuration (basically setting up the offload bits).
This requires skipping some of the low level TUN/TAP setup.
To avoid adding yet another option, we extend the 'tapif' option
to detect the use of a file (such as /dev
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 infrastructu
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
Acked-by: Will Deacon
Signed-off-by: Marc Zyngier
---
arch/arm64/include/as
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 patch
So far, we configured the world-switch by having a small array
of pointers to the save and restore functions, depending on the
GIC used on the platform.
Loading these values each time is a bit silly (they never change),
and it makes sense to rely on the instruction patching instead.
This leads to
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: A
Patching an instruction sometimes requires extracting the immediate
field from this instruction. To facilitate this, and avoid
potential duplication of code, add aarch64_insn_decode_immediate
as the reciprocal to aarch64_insn_encode_immediate.
Acked-by: Will Deacon
Signed-off-by: Marc Zyngier
--
Hi Tixy,
On 27/03/15 10:42, Jon Medhurst (Tixy) wrote:
> On Thu, 2015-03-26 at 22:19 +, Marc Zyngier wrote:
>> On Thu, 26 Mar 2015 22:03:23 +
>> Will Deacon wrote:
>>
>>> On Thu, Mar 19, 2015 at 01:59:33PM +, Marc Zyngier wrote:
Since all immediate branches are PC-relative on Aar
On 2015/3/27 9:31, Marcelo Tosatti wrote:
On Wed, Mar 25, 2015 at 05:09:13PM +, Marc Zyngier wrote:
On 23/03/15 15:58, Andre Przywara wrote:
In kvm_destroy_vm() we call kvm_io_bus_destroy() pretty early,
especially before calling kvm_arch_destroy_vm(). To avoid
unregistering devices from th
On Thu, 2015-03-26 at 22:19 +, Marc Zyngier wrote:
> On Thu, 26 Mar 2015 22:03:23 +
> Will Deacon wrote:
>
> > On Thu, Mar 19, 2015 at 01:59:33PM +, Marc Zyngier wrote:
> > > Since all immediate branches are PC-relative on Aarch64, these
> > > instructions cannot be used as an alterna
On Thu, Mar 26, 2015 at 07:50:06PM +0100, Ard Biesheuvel wrote:
> On 26 March 2015 at 19:49, Ard Biesheuvel wrote:
> > On 26 March 2015 at 19:45, Stefano Stabellini
> > wrote:
> >> On Thu, 26 Mar 2015, Andrew Jones wrote:
> >>> On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
> >>> >
On 23/03/15 15:58, Andre Przywara wrote:
> With all of the virtual GIC emulation code now being registered with
> the kvm_io_bus, we can remove all of the old MMIO handling code and
> its dispatching functionality.
>
> Signed-off-by: Andre Przywara
> ---
> include/kvm/arm_vgic.h |2 --
>
On Fri, 27 Mar 2015 00:14:12 +
Andre Przywara wrote:
> On 03/26/2015 10:06 PM, Marc Zyngier wrote:
> > On Thu, 26 Mar 2015 14:39:37 +
> > Andre Przywara wrote:
> >
> >> Using the framework provided by the recent vgic.c changes, we
> >> register a kvm_io_bus device on mapping the virtual
20 matches
Mail list logo
