25 May, 2016
1 commit
-
This patch adds a kvm debugfs subdirectory for each VM, which is named
after its pid and file descriptor. The directories contain the same
kind of files that are already in the kvm debugfs directory, but the
data exported through them is now VM specific.This makes the debugfs kvm data a convenient alternative to the
tracepoints which already have per VM data. The debugfs data is easy
to read and low overhead.CC: Dan Carpenter [includes fixes by Dan Carpenter]
Signed-off-by: Janosch Frank
Signed-off-by: Paolo Bonzini
24 May, 2016
1 commit
-
…it/kvmarm/kvmarm into kvm-next
KVM/ARM Changes for v4.7 take 2
"The GIC is dead; Long live the GIC"
This set of changes include the new vgic, which is a reimplementation of
our horribly broken legacy vgic implementation. The two implementations
will live side-by-side (with the new being the configured default) for
one kernel release and then we'll remove it.Also fixes a non-critical issue with virtual abort injection to guests.
20 May, 2016
38 commits
-
When modifying the active state of an interrupt via the MMIO interface,
we should ensure that the write has the intended effect.If a guest sets an interrupt to active, but that interrupt is already
flushed into a list register on a running VCPU, then that VCPU will
write the active state back into the struct vgic_irq upon returning from
the guest and syncing its state. This is a non-benign race, because the
guest can observe that an interrupt is not active, and it can have a
reasonable expectations that other VCPUs will not ack any IRQs, and then
set the state to active, and expect it to stay that way. Currently we
are not honoring this case.Thefore, change both the SACTIVE and CACTIVE mmio handlers to stop the
world, change the irq state, potentially queue the irq if we're setting
it to active, and then continue.We take this chance to slightly optimize these functions by not stopping
the world when touching private interrupts where there is inherently no
possible race.Signed-off-by: Christoffer Dall
-
Now that the new VGIC implementation has reached feature parity with
the old one, add the new files to the build system and add a Kconfig
option to switch between the two versions.
We set the default to the new version to get maximum test coverage,
in case people experience problems they can switch back to the old
behaviour if needed.Signed-off-by: Andre Przywara
Acked-by: Christoffer Dall -
We now store the mapped hardware IRQ number in our struct, so we
don't need the irq_phys_map for the new VGIC.
Implement the hardware IRQ mapping on top of the reworked arch
timer interface.Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
Connect to the new VGIC to the irqfd framework, so that we can
inject IRQs.
GSI routing and MSI routing is not yet implemented.Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
Enable the VGIC operation by properly initialising the registers
in the hypervisor GIC interface.Signed-off-by: Eric Auger
Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
map_resources is the last initialization step. It is executed on
first VCPU run. At that stage the code checks that userspace has provided
the base addresses for the relevant VGIC regions, which depend on the
type of VGIC that is exposed to the guest. Also we check if the two
regions overlap.
If the checks succeeded, we register the respective register frames with
the kvm_io_bus framework.If we emulate a GICv2, the function also forces vgic_init execution if
it has not been executed yet. Also we map the virtual GIC CPU interface
onto the guest's CPU interface.Signed-off-by: Eric Auger
Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
This patch allocates and initializes the data structures used
to model the vgic distributor and virtual cpu interfaces. At that
stage the number of IRQs and number of virtual CPUs is frozen.Signed-off-by: Eric Auger
Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
This patch implements the vgic_creation function which is
called on CREATE_IRQCHIP VM IOCTL (v2 only) or KVM_CREATE_DEVICESigned-off-by: Eric Auger
Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
Implements kvm_vgic_hyp_init and vgic_probe function.
This uses the new firmware independent VGIC probing to support both ACPI
and DT based systems (code from Marc Zyngier).The vgic_global struct is enriched with new fields populated
by those functions.Signed-off-by: Eric Auger
Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
Using the VMCR accessors we provide access to GIC CPU interface state
to userland by wiring it up to the existing userland interface.
[Marc: move and make VMCR accessors static, streamline MMIO handlers]Signed-off-by: Andre Przywara
Signed-off-by: Marc Zyngier
Reviewed-by: Christoffer Dall -
Since the GIC CPU interface is always virtualized by the hardware,
we don't have CPU interface state information readily available in our
emulation if userland wants to save or restore it.
Fortunately the GIC hypervisor interface provides the VMCR register to
access the required virtual CPU interface bits.
Provide wrappers for GICv2 and GICv3 hosts to have access to this
register.Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
Userland may want to save and restore the state of the in-kernel VGIC,
so we provide the code which takes a userland request and translate
that into calls to our MMIO framework.From Christoffer:
When accessing the VGIC state from userspace we really don't want a VCPU
to be messing with the state at the same time, and the API specifies
that we should return -EBUSY if any VCPUs are running.
Check and prevent VCPUs from running by grabbing their mutexes, one by
one, and error out if we fail.
(Note: This could potentially be simplified to just do a simple check
and see if any VCPUs are running, and return -EBUSY then, without
enforcing the locking throughout the duration of the uaccess, if we
think that taking/releasing all these mutexes for every single GIC
register access is too heavyweight.)Signed-off-by: Andre Przywara
Signed-off-by: Christoffer Dall -
Userland can access the emulated GIC to save and restore its state
for initialization or migration purposes.
The kvm_io_bus API requires an absolute gpa, which does not fit the
KVM_DEV_ARM_VGIC_GRP_DIST_REGS user API, that only provides relative
offsets. So we provide a wrapper to plug into our MMIO framework and
find the respective register handler.Signed-off-by: Christoffer Dall
Signed-off-by: Andre Przywara -
This patch implements the switches for KVM_DEV_ARM_VGIC_GRP_DIST_REGS
and KVM_DEV_ARM_VGIC_GRP_CPU_REGS API which allows the userspace to
access VGIC registers.Signed-off-by: Eric Auger
Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
This patch implements the KVM_DEV_ARM_VGIC_GRP_ADDR group which
enables to set the base address of GIC regions as seen by the guest.Signed-off-by: Eric Auger
Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
kvm_vgic_addr is used by the userspace to set the base address of
the following register regions, as seen by the guest:
- distributor(v2 and v3),
- re-distributors (v3),
- CPU interface (v2).Signed-off-by: Eric Auger
Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
This patch implements the KVM_DEV_ARM_VGIC_GRP_CTRL group API
featuring KVM_DEV_ARM_VGIC_CTRL_INIT attribute. The vgic_init
function is not yet implemented though.Signed-off-by: Eric Auger
Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
This patch implements the KVM_DEV_ARM_VGIC_GRP_NR_IRQS group. This
modality is supported by both VGIC V2 and V3 KVM device as will be
other groups, hence the introduction of common helpers.Signed-off-by: Eric Auger
Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
This patch introduces the skeleton for the KVM device operations
associated to KVM_DEV_TYPE_ARM_VGIC_V2 and KVM_DEV_TYPE_ARM_VGIC_V3.At that stage kvm_vgic_create is stubbed.
Signed-off-by: Eric Auger
Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
In contrast to GICv2 SGIs in a GICv3 implementation are not triggered
by a MMIO write, but with a system register write. KVM knows about
that register already, we just need to implement the handler and wire
it up to the core KVM/ARM code.Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
Since GICv3 supports much more than the 8 CPUs the GICv2 ITARGETSR
register can handle, the new IROUTER register covers the whole range
of possible target (V)CPUs by using the same MPIDR that the cores
report themselves.
In addition to translating this MPIDR into a vcpu pointer we store
the originally written value as well. The architecture allows to
write any values into the register, which must be read back as written.Since we don't support affinity level 3, we don't need to take care
about the upper word of this 64-bit register, which simplifies the
handling a bit.Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
We implement the only one ID register that is required by the
architecture, also this is the one that Linux actually checks.Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
The redistributor TYPER tells the OS about the associated MPIDR,
also the LAST bit is crucial to determine the number of redistributors.Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
As in the GICv2 emulation we handle those three registers in one
function.Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
Create a new file called vgic-mmio-v3.c and describe the GICv3
distributor and redistributor registers there.
This adds a special macro to deal with the split of SGI/PPI in the
redistributor and SPIs in the distributor, which allows us to reuse
the existing GICv2 handlers for those registers which are compatible.
Also we provide a function to deal with the registration of the two
separate redistributor frames per VCPU.Signed-off-by: Andre Przywara
Reviewed-by: Eric Auger
Reviewed-by: Christoffer Dall -
As this register is v2 specific, its implementation lives entirely
in vgic-mmio-v2.c.
This register allows setting the source mask of an IPI.Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
Triggering an IPI via this register is v2 specific, so the
implementation lives entirely in vgic-mmio-v2.c.Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
The target register handlers are v2 emulation specific, so their
implementation lives entirely in vgic-mmio-v2.c.
We copy the old VGIC behaviour of assigning an IRQ to the first VCPU
set in the target mask instead of making it possibly pending on
multiple VCPUs.Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
The config register handlers are shared between the v2 and v3
emulation, so their implementation goes into vgic-mmio.c, to be
easily referenced from the v3 emulation as well later.Signed-off-by: Andre Przywara
-
The priority register handlers are shared between the v2 and v3
emulation, so their implementation goes into vgic-mmio.c, to be
easily referenced from the v3 emulation as well later.
There is a corner case when we change the priority of a pending
interrupt which we don't handle at the moment.Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
The active register handlers are shared between the v2 and v3
emulation, so their implementation goes into vgic-mmio.c, to be
easily referenced from the v3 emulation as well later.
Since activation/deactivation of an interrupt may happen entirely
in the guest without it ever exiting, we need some extra logic to
properly track the active state.
For clearing the active state, we basically have to halt the guest to
make sure this is properly propagated into the respective VCPUs.Signed-off-by: Andre Przywara
-
The pending register handlers are shared between the v2 and v3
emulation, so their implementation goes into vgic-mmio.c, to be easily
referenced from the v3 emulation as well later.
For level triggered interrupts the real line level is unaffected by
this write, so we keep this state separate and combine it with the
device's level to get the actual pending state.Signed-off-by: Andre Przywara
Reviewed-by: Marc Zyngier
Reviewed-by: Christoffer Dall -
As the enable register handlers are shared between the v2 and v3
emulation, their implementation goes into vgic-mmio.c, to be easily
referenced from the v3 emulation as well later.Signed-off-by: Andre Przywara
Reviewed-by: Marc Zyngier
Reviewed-by: Christoffer Dall -
Those three registers are v2 emulation specific, so their implementation
lives entirely in vgic-mmio-v2.c. Also they are handled in one function,
as their implementation is pretty simple.
When the guest enables the distributor, we kick all VCPUs to get
potentially pending interrupts serviced.Signed-off-by: Marc Zyngier
Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
Create vgic-mmio-v2.c to describe GICv2 emulation specific handlers
using the initializer macros provided by the VGIC MMIO framework.
Provide a function to register the GICv2 distributor registers to
the kvm_io_bus framework.
The actual handler functions are still stubs in this patch.Signed-off-by: Andre Przywara
Signed-off-by: Marc Zyngier
Reviewed-by: Christoffer Dall -
Add an MMIO handling framework to the VGIC emulation:
Each register is described by its offset, size (or number of bits per
IRQ, if applicable) and the read/write handler functions. We provide
initialization macros to describe each GIC register later easily.Separate dispatch functions for read and write accesses are connected
to the kvm_io_bus framework and binary-search for the responsible
register handler based on the offset address within the region.
We convert the incoming data (referenced by a pointer) to the host's
endianess and use pass-by-value to hand the data over to the actual
handler functions.The register handler prototype and the endianess conversion are
courtesy of Christoffer Dall.Signed-off-by: Marc Zyngier
Signed-off-by: Christoffer Dall
Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall -
Tell KVM whether a particular VCPU has an IRQ that needs handling
in the guest. This is used to decide whether a VCPU is runnable.Signed-off-by: Eric Auger
Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall
Reviewed-by: Marc Zyngier -
As the GICv3 virtual interface registers differ from their GICv2
siblings, we need different handlers for processing maintenance
interrupts and reading/writing to the LRs.
Implement the respective handler functions and connect them to
existing code to be called if the host is using a GICv3.Signed-off-by: Marc Zyngier
Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall
