On Thu, Oct 12, 2017 at 12:41:30PM +0200, Christoffer Dall wrote:
> Handle accesses to any AArch32 EL1 system registers where we can defer
> saving and restoring them to vcpu_load and vcpu_put, and which are
> stored in special EL2 registers only used support 32-bit guests.
>
> Signed-off-by:
On Thu, Oct 12, 2017 at 12:41:29PM +0200, Christoffer Dall wrote:
> Handle accesses during traps to any remaining EL1 registers which can be
> deferred to vcpu_load and vcpu_put, by either accessing them directly on
> the physical CPU when the latest version is stored there, or by
> synchronizing
On 13 November 2017 at 16:14, Andrew Jones wrote:
> On Mon, Nov 13, 2017 at 12:29:46PM +0100, Christoffer Dall wrote:
>> I'm thinking this is analogous to migrating a VM that uses an irqchip in
>> userspace and has set the IRQ or FIQ lines using KVM_IRQ_LINE. My
>> feeling is
On Thu, Oct 12, 2017 at 12:41:27PM +0200, Christoffer Dall wrote:
> When we defer the save/restore of system registers to vcpu_load and
> vcpu_put, we need to take care of the emulation code that handles traps
> to these registers, since simply reading the memory array will return
> stale data.
>
On Thu, Oct 12, 2017 at 12:41:26PM +0200, Christoffer Dall wrote:
> We currently handle 32-bit accesses to trapped VM system registers using
> the 32-bit index into the coproc array on the vcpu structure, which is a
> union of the coprog array and the sysreg array.
coproc
>
> Since all the
On Mon, Nov 13, 2017 at 12:29:46PM +0100, Christoffer Dall wrote:
> On Thu, Nov 09, 2017 at 06:14:56PM +, James Morse wrote:
> > Hi guys,
> >
> > On 19/10/17 15:57, James Morse wrote:
> > > Known issues:
> > [...]
> > > * KVM-Migration: VDISR_EL2 is exposed to userspace as DISR_EL1, but how
Julien Thierry writes:
> Hi Alex,
>
> On 09/11/17 17:00, Alex Bennée wrote:
>> The system state of KVM when using userspace emulation is not complete
>> until we return into KVM_RUN. To handle mmio related updates we wait
>> until they have been committed and then
On 13 November 2017 at 11:29, Christoffer Dall wrote:
> I'm thinking this is analogous to migrating a VM that uses an irqchip in
> userspace and has set the IRQ or FIQ lines using KVM_IRQ_LINE. My
> feeling is that this is also not supported today.
Oops, yes, we completely
On Thu, Nov 09, 2017 at 06:14:56PM +, James Morse wrote:
> Hi guys,
>
> On 19/10/17 15:57, James Morse wrote:
> > Known issues:
> [...]
> > * KVM-Migration: VDISR_EL2 is exposed to userspace as DISR_EL1, but how
> > should
> >HCR_EL2.VSE or VSESR_EL2 be migrated when the guest has an
Hi Alex,
On 09/11/17 17:00, Alex Bennée wrote:
The system state of KVM when using userspace emulation is not complete
until we return into KVM_RUN. To handle mmio related updates we wait
until they have been committed and then schedule our KVM_EXIT_DEBUG.
The kvm_arm_handle_step_debug() helper
On 09/11/17 17:00, Alex Bennée wrote:
If we are using guest debug to single-step the guest we need to ensure
we exit after emulating the instruction. This only affects
instructions completely emulated by the kernel. For userspace emulated
instructions we need to exit and return to complete the
On Wed, Nov 08, 2017 at 04:06:24PM +, James Morse wrote:
> dpm_suspend() calls the freeze/thaw callbacks for hibernate before
> disable_non_bootcpus() takes down secondaries.
>
> This leads to a fun race where the freeze/thaw callbacks reset the
> SDEI interface (as we may be restoring a
On 09/11/17 17:00, Alex Bennée wrote:
After emulating instructions we may want return to user-space to
handle a single-step. If single-step is enabled the helper set the run
structure for return and returns true.
Signed-off-by: Alex Bennée
With the fixup:
From: Marc Zyngier
Yet another braindump so I can free some cells...
Acked-by: Christoffer Dall
Signed-off-by: Marc Zyngier
Signed-off-by: Christoffer Dall
---
virt/kvm/arm/vgic/vgic-v4.c |
From: Marc Zyngier
There is no need to perform an INV for each interrupt when updating
multiple interrupts. Instead, we can rely on the final VINVALL that
gets sent to the ITS to do the work for all of them.
Acked-by: Christoffer Dall
Reviewed-by: Eric
From: Eric Auger
We want to reuse the core of the map/unmap functions for IRQ
forwarding. Let's move the computation of the hwirq in
kvm_vgic_map_phys_irq and pass the linux IRQ as parameter.
the host_irq is added to struct vgic_irq.
We introduce kvm_vgic_map/unmap_irq
From: Marc Zyngier
The redistributor needs to be told which vPE is about to be run,
and tells us whether there is any pending VLPI on exit.
Let's add the scheduling calls to the vgic flush/sync functions,
allowing the VLPIs to be delivered to the guest.
Reviewed-by:
From: Marc Zyngier
Handling CLEAR is pretty easy. Just ask the ITS driver to clear
the corresponding pending bit (which will turn into a CLEAR
command on the physical side).
Acked-by: Christoffer Dall
Signed-off-by: Marc Zyngier
From: Marc Zyngier
The whole MSI injection process is fairly monolithic. An MSI write
gets turned into an injected LPI in one swift go. But this is actually
a more fine-grained process:
- First, a virtual ITS gets selected using the doorbell address
- Then the
We should only try to initialize GICv4 data structures on a GICv4
capable system. Move the vgic_supports_direct_msis() check inito
vgic_v4_init() so that any KVM VGIC initialization path does not fail
on non-GICv4 systems.
Also be slightly more strict in the checking of the return value in
From: Marc Zyngier
The way we call kvm_vgic_destroy is a bit bizarre. We call it
*after* having freed the vcpus, which sort of defeats the point
of cleaning up things before that point.
Let's move kvm_vgic_destroy towards the beginning of kvm_arch_destroy_vm,
which seems
From: Marc Zyngier
When a vPE is not running, a VLPI being made pending results in a
doorbell interrupt being delivered. Let's handle this interrupt
and update the pending_last flag that indicates that VLPIs are
pending. The corresponding vcpu is also kicked into action.
From: Marc Zyngier
Upon updating a property, we propagate it all the way to the physical
ITS, and ask for an INV command to be executed there.
Acked-by: Christoffer Dall
Signed-off-by: Marc Zyngier
Signed-off-by: Christoffer Dall
From: Eric Auger
This patch selects IRQ_BYPASS_MANAGER and HAVE_KVM_IRQ_BYPASS
configs for ARM/ARM64.
kvm_arch_has_irq_bypass() now is implemented and returns true.
As a consequence the irq bypass consumer will be registered for
ARM/ARM64 with the forwarding callbacks:
-
From: Marc Zyngier
In order to help integrating the vITS code with GICv4, let's add
a new helper that deals with updating the affinity of an LPI,
which will later be augmented with super duper extra GICv4
goodness.
Reviewed-by: Christoffer Dall
From: Marc Zyngier
When freeing an LPI (on a DISCARD command, for example), we need
to unmap the VLPI down to the physical ITS level.
Acked-by: Christoffer Dall
Signed-off-by: Marc Zyngier
Signed-off-by: Christoffer Dall
From: Marc Zyngier
The doorbell interrupt is only useful if the vcpu is blocked on WFI.
In all other cases, recieving a doorbell interrupt is just a waste
of cycles.
So let's only enable the doorbell if a vcpu is getting blocked,
and disable it when it is unblocked. This
From: Marc Zyngier
When a vPE exits, the pending_last flag is set when there are pending
VLPIs stored in the pending table. Similarily, this flag will be set
when a doorbell interrupt fires, as it indicates the same condition.
Let's update kvm_vgic_vcpu_pending_irq() to
From: Marc Zyngier
The GICv4 architecture doesn't make it easy for save/restore to
work, as it doesn't give any guarantee that the pending state
is written into the pending table.
So let's not take any chance, and let's return an error if
we encounter any LPI that has the
Hi Paolo and Radim,
Here is the second pull request for KVM/ARM for v4.15. These changes
introduce GICv4 support in KVM/ARM, allowing direct injection of LPIs
from devices generating MSIs into VMs. The changes rely on irqchip
infrastructure for GICv4 already merged in tip:irq/core.
The pull
From: Marc Zyngier
The GICv4 support introduces a hard dependency between the KVM
core and the ITS infrastructure. arm64 already selects it at
the architecture level, but 32bit doesn't. In order to avoid
littering the kernel with #ifdefs, let's just select the whole
of the
From: Marc Zyngier
When the guest issues an affinity change, we need to tell the physical
ITS that we're now targetting a new vcpu. This is done by extracting
the current mapping, updating the target, and reapplying the mapping.
Reviewed-by: Christoffer Dall
From: Marc Zyngier
If the guest issues an INT command targetting a VLPI, let's
call into the irq_set_irqchip_state() helper to make it pending
on the physical side.
This works just as well if userspace decides to inject an interrupt
using the normal userspace API...
From: Marc Zyngier
In order to control the GICv4 view of virtual CPUs, we rely
on an irqdomain allocated for that purpose. Let's add a couple
of helpers to that effect.
At the same time, the vgic data structures gain new fields to
track all this... erm... wonderful stuff.
From: Marc Zyngier
Let's use the irq bypass mechanism also used for x86 posted interrupts
to intercept the virtual PCIe endpoint configuration and establish our
LPI->VLPI mapping.
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
From: Marc Zyngier
Add a new has_gicv4 field in the global VGIC state that indicates
whether the HW is GICv4 capable, as a per-VM predicate indicating
if there is a possibility for a VM to support direct injection
(the above being true and the VM having an ITS).
From: Marc Zyngier
In order for VLPIs to be delivered to the guest, we must make sure that
the virtual cpuif is always enabled, irrespective of the presence of
virtual interrupt in the LRs.
Acked-by: Christoffer Dall
Reviewed-by: Eric Auger
From: Marc Zyngier
We so far allocate the doorbell interrupts without taking any
special measure regarding the affinity of these interrupts. We
simply move them around as required when the vcpu gets scheduled
on a different CPU.
But that's counting without userspace (and
From: Marc Zyngier
The current implementation of MOVALL doesn't allow us to call
into the core ITS code as we hold a number of spinlocks.
Let's try a method used in other parts of the code, were we copy
the intids of the candicate interrupts, and then do whatever
we need
39 matches
Mail list logo