[PATCH v3 59/59] irqchip/gic-v3-its: Workaround Huawei D05 redistributor addressing

The ITSes on the Huawei D05 are broken when it comes to addressing the redistributors, and need to be explicitely told to address the VLPI page instead of the redistributor base address. So let's add yet another quirk, fixing up the target address in the command stream. Signed-off-by: Marc

[PATCH v3 49/59] KVM: arm/arm64: GICv4: Propagate VLPI properties at map time

When the VLPI gets mapped, it must inherit the configuration of LPI configured at the vITS level. FOr that purpose, let's make update_lpi_config globally available and call it just after having performed the VLPI map operation. Signed-off-by: Marc Zyngier ---

[PATCH v3 51/59] KVM: arm/arm64: GICv4: Add doorbell interrupt handling

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. Signed-off-by: Marc Zyngier

[PATCH v3 54/59] KVM: arm/arm64: GICv4: Enable virtual cpuif if VLPIs can be delivered

In order for VLPIs to be delivered to the guest, we must make sure that the cpuif is always enabled, irrespective of the presence of virtual interrupt in the LRs. Signed-off-by: Marc Zyngier --- virt/kvm/arm/hyp/vgic-v3-sr.c | 9 ++--- 1 file changed, 6 insertions(+),

[PATCH v3 58/59] irqchip/gic-v3-its: Pass its_node pointer to each command bulder

In order to be able to issue command variants depending on how broken an ITS is, let's pass the its pointer to all command building primitives. Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3-its.c | 58 ++-- 1 file changed,

[PATCH v3 40/59] KVM: arm/arm64: GICv4: Add init/teardown of the per-VM vPE irq domain

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. They way we hook into the vgic init is

[PATCH v3 50/59] KVM: arm/arm64: GICv4: Use pending_last as a scheduling hint

When a vPE exits, the pending_last flag is set when there are pending VLPIs stored in the pending table. Similarily, we set this flag when a doorbell interrupt fires, as it indicates the same condition. Let's update kvm_vgic_vcpu_pending_irq() to account for that flag as well, making a vcpu

[PATCH v3 55/59] KVM: arm/arm64: GICv4: Enable VLPI support

All it takes is the has_v4 flag to be set in gic_kvm_info as well as "kvm-arm.vgic_v4_enable=1" being passed on the command line for GICv4 to be enabled in KVM. Signed-off-by: Marc Zyngier --- Documentation/admin-guide/kernel-parameters.txt | 4

[PATCH v3 52/59] KVM: arm/arm64: GICv4: Use the doorbell interrupt as an unblocking source

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 is very similar to what we're doing for the

[PATCH v3 57/59] KVM: arm/arm64: GICv4: Theory of operations

Yet another braindump so I can free some cells... Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-v4.c | 68 + 1 file changed, 68 insertions(+) diff --git a/virt/kvm/arm/vgic/vgic-v4.c b/virt/kvm/arm/vgic/vgic-v4.c index

[PATCH v3 36/59] KVM: arm: Select ARM_GIC_V3 and ARM_GIC_V3_ITS

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 GICv3 suport code. You know you want it.

[PATCH v3 43/59] KVM: arm/arm64: GICv4: Unmap VLPI when freeing an LPI

When freeing an LPI (on a DISCARD command, for example), we need to unmap the VLPI down to the physical ITS level. Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-its.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

[PATCH v3 41/59] KVM: arm/arm64: GICv4: Wire mapping/unmapping of VLPIs in VFIO irq bypass

Let's use the irq bypass mechanism introduced for platform device interrupts to intercept the virtual PCIe endpoint configuration and establish our LPI->VLPI mapping. Signed-off-by: Marc Zyngier --- include/kvm/arm_vgic.h | 8 virt/kvm/arm/arm.c | 27

[PATCH v3 53/59] KVM: arm/arm64: GICv4: Hook vPE scheduling into vgic flush/sync

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. Signed-off-by: Marc Zyngier ---

[PATCH v3 37/59] KVM: arm/arm64: vgic: Move kvm_vgic_destroy call around

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 more sensible. Signed-off-by: Marc Zyngier

[PATCH v3 47/59] KVM: arm/arm64: GICv4: Propagate property updates to VLPIs

Upon updating a property, we propagate it all the way to the physical ITS, and ask for an INV command to be executed there. Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-its.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/virt/kvm/arm/vgic/vgic-its.c

[PATCH v3 56/59] KVM: arm/arm64: GICv4: Prevent heterogenous systems from using GICv4

The GICv4 architecture doesn't prevent CPUs implementing GICv4 to cohabit with CPUs limited to GICv3 in the same system. This is mad (the sheduler would have to be made aware of the v4 capability), and we're certainly not going to support this any time soon. So let's check that all online CPUs

[PATCH v3 44/59] KVM: arm/arm64: GICv4: Handle MOVI applied to a VLPI

When the guest issues a MOVI, 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. The core ITS code should do the right thing. Signed-off-by: Marc Zyngier ---

[PATCH v3 46/59] KVM: arm/arm64: GICv4: Handle MOVALL applied to a vPE

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 to do with them outside of the critical

[PATCH v3 45/59] KVM: arm/arm64: GICv4: Handle CLEAR applied to a VLPI

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). Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-its.c | 4 1 file changed, 4 insertions(+) diff --git

[PATCH v3 42/59] KVM: arm/arm64: GICv4: Handle INT command applied to a VLPI

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... Signed-off-by: Marc Zyngier

[PATCH v3 38/59] KVM: arm/arm64: vITS: Add MSI translation helpers

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 DevID/EventID pair gets translated into an LPI -

[PATCH v3 39/59] KVM: arm/arm64: GICv4: Add property field and per-VM predicate

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). Signed-off-by: Marc Zyngier

[PATCH v3 32/59] irqchip/gic-v4: Add VLPI configuration interface

Add the required interfaces to map, unmap and update a VLPI. Reviewed-by: Eric Auger Reviewed-by: Thomas Gleixner Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v4.c | 42 ++

[PATCH v3 35/59] irqchip/gic-v3: Advertise GICv4 support to KVM

As KVM needs to know about the availability of GICv4 to enable direct injection of interrupts, let's advertise the feature in the gic_kvm_info structure. Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3.c | 2 ++ include/linux/irqchip/arm-gic-common.h |

[PATCH v3 33/59] irqchip/gic-v4: Add some basic documentation

Do a braindump of the way things are supposed to work. Reviewed-by: Thomas Gleixner Reviewed-by: Eric Auger Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v4.c | 71 1 file

[PATCH v3 29/59] irqchip/gic-v3-its: Set implementation defined bit to enable VLPIs

A long time ago, GITS_CTLR[1] used to be called GITC_CTLR.EnableVLPI. It has been subsequently deprecated and is now an "Implementation Defined" bit that may ot may not be set for GICv4. Brilliant. And the current crop of the FastModel requires that bit for VLPIs to be enabled. Oh well... Let's

[PATCH v3 10/59] irqchip/gic-v3-its: Split out pending table allocation

Just as for the property table, let's move the pending table allocation to a separate function. Reviewed-by: Thomas Gleixner Reviewed-by: Eric Auger Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3-its.c | 29

[PATCH v3 31/59] irqchip/gic-v4: Add VPE command interface

Add the required interfaces to schedule a VPE and perform a VINVALL command. Reviewed-by: Thomas Gleixner Reviewed-by: Eric Auger Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v4.c | 25 +

[PATCH v3 34/59] irqchip/gic-v4: Enable low-level GICv4 operations

Get the show on the road... Reviewed-by: Thomas Gleixner Signed-off-by: Marc Zyngier --- drivers/irqchip/Makefile | 2 +- drivers/irqchip/irq-gic-v3-its.c | 3 ++- drivers/irqchip/irq-gic-v4.c | 13 +

[PATCH v3 19/59] irqchip/gic-v3-its: Add VPE domain infrastructure

Add the basic GICv4 VPE (vcpu in GICv4 parlance) infrastructure (irqchip, irq domain) that is going to be populated in the following patches. Reviewed-by: Eric Auger Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3-its.c | 33

[PATCH v3 17/59] irqchip/gic-v3-its: Add VLPI map/unmap operations

In order to let a VLPI being injected into a guest, the VLPI must be mapped using the VMAPTI command. When moved to a different vcpu, it must be moved with the VMOVI command. These commands are issued via the irq_set_vcpu_affinity method, making sure we unmap the corresponding host LPI first.

[PATCH v3 27/59] irqchip/gic-v3-its: Support VPE doorbell invalidation even when !DirectLPI

When we don't have the DirectLPI feature, we must work around the architecture shortcomings to be able to perform the required invalidation. For this, we create a fake device whose sole purpose is to provide a way to issue a map/inv/unmap sequence (and the corresponding sync operations). That's 6

[PATCH v3 15/59] irqchip/gic-v3-its: Add GICv4 ITS command definitions

Add the new GICv4 ITS command definitions, most of them, being defined in terms of their physical counterparts. Reviewed-by: Eric Auger Reviewed-by: Thomas Gleixner Signed-off-by: Marc Zyngier ---

[PATCH v3 22/59] irqchip/gic-v3-its: Add VPENDBASER/VPROPBASER accessors

V{PEND,PROP}BASER being 64bit registers, they need some ad-hoc accessors on 32bit, specially given that VPENDBASER contains a Valid bit, making the access a bit convoluted. Reviewed-by: Thomas Gleixner Reviewed-by: Eric Auger Signed-off-by: Marc

[PATCH v3 11/59] irqchip/gic-v3-its: Rework LPI freeing

Rework LPI deallocation so that it can be reused by the v4 support code. Reviewed-by: Eric Auger Reviewed-by: Thomas Gleixner Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3-its.c | 13 +++-- 1 file changed, 7

[PATCH v3 09/59] irqchip/gic-v3-its: Allow use of indirect VCPU tables

The VCPU tables can be quite sparse as well, and it makes sense to use indirect tables as well if possible. Reviewed-by: Thomas Gleixner Reviewed-by: Eric Auger Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3-its.c |

[PATCH v3 16/59] irqchip/gic-v3-its: Add VLPI configuration hook

Add the skeleton irq_set_vcpu_affinity method that will be used to configure VLPIs. Reviewed-by: Eric Auger Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3-its.c | 24 1 file changed, 24 insertions(+) diff --git

[PATCH v3 25/59] irqchip/gic-v3-its: Add VPE affinity changes

When we're about to run a vcpu, it is crucial that the redistributor associated with the physical CPU is being told about the new residency. This is abstracted by hijacking the irq_set_affinity method for the doorbell interrupt associated with the VPE. It is expected that the hypervisor will call

[PATCH v3 30/59] irqchip/gic-v4: Add per-VM VPE domain creation

When creating a VM, it is very convenient to have an irq domain containing all the doorbell interrupts associated with that VM (each interrupt representing a VPE). Reviewed-by: Thomas Gleixner Signed-off-by: Marc Zyngier ---

[PATCH v3 26/59] irqchip/gic-v3-its: Add VPE interrupt masking

When masking/unmasking a doorbell interrupt, it is necessary to issue an invalidation to the corresponding redistributor. We use the DirectLPI feature by writting directly to the corresponding redistributor. Reviewed-by: Thomas Gleixner Signed-off-by: Marc Zyngier

[PATCH v3 14/59] irqchip/gic-v4: Add management structure definitions

Add a bunch of GICv4-specific data structures that will get used in subsequent patches. Reviewed-by: Thomas Gleixner Signed-off-by: Marc Zyngier --- include/linux/irqchip/arm-gic-v4.h | 92 ++ 1 file changed, 92

[PATCH v3 21/59] irqchip/gic-v3-its: Add VPE irq domain [de]activation

On activation, a VPE is mapped using the VMAPP command, followed by a VINVALL for a good measure. On deactivation, the VPE is simply unmapped. Reviewed-by: Thomas Gleixner Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3-its.c | 102

[PATCH v3 24/59] irqchip/gic-v3-its: Add VPE invalidation hook

When a guest issues a INVALL command targetting a collection, it must be translated into a VINVALL for the VPE that has this collection. This patch implements a hook that offers this functionallity to the hypervisor. Reviewed-by: Thomas Gleixner Signed-off-by: Marc Zyngier

[PATCH v3 28/59] irqchip/gic-v3-its: Allow doorbell interrupts to be injected/cleared

While the doorbell interrupts are usually driven by the HW itself, having a way to trigger them independently has proved to be a really useful debug feature. As it is actually very little code, let's add it to the VPE irqchip operations. Signed-off-by: Marc Zyngier ---

[PATCH v3 23/59] irqchip/gic-v3-its: Add VPE scheduling

When a VPE is scheduled to run, the corresponding redistributor must be told so, by setting VPROPBASER to the VM's property table, and VPENDBASER to the vcpu's pending table. When scheduled out, we preserve the IDAI and PendingLast bits. The latter is specially important, as it tells the

[PATCH v3 20/59] irqchip/gic-v3-its: Add VPE irq domain allocation/teardown

When creating a VM, the low level GICv4 code is responsible for: - allocating each VPE a unique VPEID - allocating a doorbell interrupt for each VPE - allocating the pending tables for each VPE - allocating the property table for the VM This of course has to be reversed when the VM is brought

[PATCH v3 18/59] irqchip/gic-v3-its: Add VLPI configuration handling

When a VLPI is reconfigured (enabled, disabled, change in priority), the full configuration byte must be written, and the caches invalidated. Also, when using the irq_mask/irq_unmask methods, it is necessary to disable the doorbell for that particular interrupt (by mapping it to 1023) on top of

[PATCH v3 13/59] irqchip/gic-v3-its: Generalize LPI configuration

We're are going to need to change a bit more than just the enable bit in the LPI property table in the future. So let's change the LPI configuration funtion to take a set of bits to be cleared, and a set of bits to be set. This way, we'll be able to use it when a guest updates an LPI property

[PATCH v3 12/59] irqchip/gic-v3-its: Generalize device table allocation

As we want to use 2-level tables for VCPUs, let's hack the device table allocator in order to make it slightly more generic. It will get reused in subsequent patches. Reviewed-by: Thomas Gleixner Reviewed-by: Eric Auger Signed-off-by: Marc Zyngier

[PATCH v3 05/59] irqchip/gic-v3-its: Add probing for VLPI properties

Add the probing code for the ITS VLPI support. This includes configuring the ITS number if not supporting the single VMOVP command feature. Reviewed-by: Eric Auger Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3-its.c | 71

[PATCH v3 01/59] genirq: Let irq_set_vcpu_affinity() iterate over hierarchy

When assigning an interrupt to a vcpu, it is not unlikely that the level of the hierarchy implementing irq_set_vcpu_affinity is not the top level (think a generic MSI domain on top of a virtualization aware interrupt controller). In such a case, let's iterate over the hierarchy until we find an

[PATCH v3 08/59] irqchip/gic-v3-its: Split out property table allocation

Move the LPI property table allocation into its own function, as this is going to be required for those associated with VMs in the future. Reviewed-by: Eric Auger Reviewed-by: Thomas Gleixner Signed-off-by: Marc Zyngier ---

[PATCH v3 06/59] irqchip/gic-v3-its: Macro-ize its_send_single_command

Most ITS commands do operate on a collection object, and require a SYNC command to be performed on that collection in order to guarantee the execution of the first command. With GICv4 ITS, another set of commands perform similar operations on a VPE object, and a VSYNC operations must be executed

[PATCH v3 03/59] irqchip/gic-v3: Add VLPI/DirectLPI discovery

Add helper functions that probe for VLPI and DirectLPI properties. Reviewed-by: Eric Auger Reviewed-by: Thomas Gleixner Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3.c | 24 +++-

[PATCH v3 00/59] irqchip: KVM: Add support for GICv4

This (monster of a) series implements full support for GICv4, bringing direct injection of MSIs to KVM on arm and arm64, assuming you have the right hardware (which is quite unlikely). To get an idea of the design, I'd recommend you start with patches #33 and #57, which try to shed some light on

[PATCH v3 04/59] irqchip/gic-v3-its: Move LPI definitions around

The various LPI definitions are in the middle of the code, and would be better placed at the beginning, given that we're going to use some of them much earlier. Reviewed-by: Thomas Gleixner Reviewed-by: Eric Auger Signed-off-by: Marc Zyngier

答复: [PATCH v4 3/3] arm64: kvm: inject SError with user space specified syndrome

Hi James. You are right. For the SEI case, the ESR_EL1 may not need to refer to ESR_EL2's value. But for the SEA case, the ESR_EL1 may need to refer to ESR_EL2's value. For example, the 16bit/32bit instruction-length, it may needs to check the ESR_EL2's bit 25. Because when happen

Re: [RFC PATCH v2 00/38] Nested Virtualization on KVM/ARM

Hi Jintack, On Tue, Jul 18, 2017 at 11:58:26AM -0500, Jintack Lim wrote: > Nested virtualization is the ability to run a virtual machine inside another > virtual machine. In other words, it’s about running a hypervisor (the guest > hypervisor) on top of another hypervisor (the host hypervisor). >

Re: [RFC PATCH v2 38/38] KVM: arm64: Respect the virtual CPTR_EL2.TCPAC setting

On Tue, Jul 18, 2017 at 11:59:04AM -0500, Jintack Lim wrote: > Forward CPACR_EL1 traps to the virtual EL2 if virtual CPTR_EL2 is > configured to trap CPACR_EL1 accesses from EL1. > > This is for recursive nested virtualization. > > Signed-off-by: Jintack Lim > --- >

Re: [RFC PATCH v2 37/38] KVM: arm64: Respect the virtual HCR_EL2.NV1 bit setting

On Tue, Jul 18, 2017 at 11:59:03AM -0500, Jintack Lim wrote: > Forward ELR_EL1, SPSR_EL1 and VBAR_EL1 traps to the virtual EL2 if the > virtual HCR_EL2.NV bit is set. > > This is for recursive nested virtualization. > > Signed-off-by: Jintack Lim > --- >

Re: [RFC PATCH v2 36/38] KVM: arm64: Respect virtual HCR_EL2.TVM and TRVM settings

On Tue, Jul 18, 2017 at 11:59:02AM -0500, Jintack Lim wrote: > Forward the EL1 virtual memory register traps to the virtual EL2 if they > are not coming from the virtual EL2 and the virtual HCR_EL2.TVM or TRVM > bit is set. I noticed that all these recursive patches don't change how we program

Re: [RFC PATCH v2 35/38] KVM: arm64: Respect the virtual HCR_EL2.NV bit setting for EL12 register traps

On Tue, Jul 18, 2017 at 11:59:01AM -0500, Jintack Lim wrote: > In addition to EL2 register accesses, setting NV bit will also make EL12 > register accesses trap to EL2. To emulate this for the virtual EL2, > forword traps due to EL12 register accessses to the virtual EL2 if the > virtual

Re: [RFC PATCH v2 33/38] KVM: arm64: Emulate appropriate VM control system registers

On Tue, Jul 18, 2017 at 11:58:59AM -0500, Jintack Lim wrote: > Now that the virtual EL2 can access EL2 register states via EL1 > registers, we need to consider it when selecting the register to > emulate. I don't really understand what this patch does from the commit message. >From looking at

Re: [RFC PATCH v2 32/38] KVM: arm64: Trap and emulate CPTR_EL2 accesses via CPACR_EL1 from the virtual EL2 with VHE

On Tue, Jul 18, 2017 at 11:58:58AM -0500, Jintack Lim wrote: > While the EL1 virtual memory control registers can be accessed in the > virtual EL2 with VHE without trap to manuplate the virtual EL2 states, > we can't do that for CPTR_EL2 for an unfortunate reason. > > This is because the top bit

Re: [RFC PATCH v2 31/38] KVM: arm64: Manage the shadow states when virtual E2H bit enabled

On Tue, Jul 18, 2017 at 11:58:57AM -0500, Jintack Lim wrote: In the subject: s/virtual E2H bit enabled/virtual E2H bit is set/ > When creating the shadow context for the virtual EL2 execution, we can > directly copy the EL2 register states to the shadow EL1 register states > if the virtual

Re: [RFC PATCH v2 30/38] KVM: arm64: Allow the virtual EL2 to access EL2 states without trap

On Tue, Jul 18, 2017 at 11:58:56AM -0500, Jintack Lim wrote: > When the virtual E2H bit is set, we can support EL2 register accesses > via EL1 registers from the virtual EL2 by doing trap-and-emulate. A > better alternative, however, is to allow the virtual EL2 to access EL2 > register states

Re: [RFC PATCH v2 29/38] KVM: arm64: Support a VM with VHE considering EL0 of the VHE host

On Tue, Jul 18, 2017 at 11:58:55AM -0500, Jintack Lim wrote: nit: The subject is a little hard to understand. > On VHE systems, EL0 of the host kernel is considered as a part of 'VHE > host'; The execution of EL0 is affected by system registers set by the > VHE kernel including the hypervisor.