- 31 Aug, 2017 32 commits
-
-
Minghuan Lian authored
In order to maximize the use of MSI, a PCIe controller will share all MSI controllers. The patch changes "msi-parent" to refer to all MSI controller dts nodes. Signed-off-by:
Minghuan Lian <Minghuan.Lian@nxp.com> Signed-off-by:
Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Minghuan Lian authored
In order to maximize the use of MSI, a PCIe controller will share all MSI controllers. The patch changes msi-parent to refer to all MSI controller dts nodes. Signed-off-by:
-
Minghuan Lian authored
"1" should be replaced by "l". This is a typo. The patch is to fix it. Signed-off-by:
-
Minghuan Lian authored
"1" should be replaced by "l". This is a typo. The patch is to fix it. Signed-off-by:
-
Minghuan Lian authored
The patch is to fix typo of the Layerscape SCFG MSI dts compatible strings. "1" is replaced by "l". Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Florian Fainelli authored
Initialization of irq_fwd_mask was done using __raw_writel() which happens to work for all cases except when using ARM BE8 which requires writel() (with the proper swapping). Move the initialization of the irq_fwd_mask till later when we have correctly defined our I/O accessors. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Bhumika Goyal authored
Make these const as they are only used during a copy operation. Done using Coccinelle. @match disable optional_qualifier@ identifier s; @@ static struct mmp_intc_conf s = {...}; @ref@ position p; identifier match.s; @@ s@p @good1@ position ref.p; identifier match.s,f,c; expression e; @@ ( e = s@p | e = s@p.f | c(...,s@p.f,...) | c(...,s@p,...) ) @bad depends on !good1@ position ref.p; identifier match.s; @@ s@p @depends on forall !bad disable optional_qualifier@ identifier match.s; @@ static + const struct mmp_intc_conf s; Signed-off-by:Bhumika Goyal <bhumirks@gmail.com> Signed-off-by:
-
Bhumika Goyal authored
Make this const as it is only used in a copy operation. Done using Coccinelle. Signed-off-by:
-
Marc Zyngier authored
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 authored
Get the show on the road... Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Marc Zyngier authored
Do a braindump of the way things are supposed to work. Reviewed-by:
Eric Auger <eric.auger@redhat.com> Signed-off-by:
-
Marc Zyngier authored
Add the required interfaces to map, unmap and update a VLPI. Reviewed-by:
-
Marc Zyngier authored
Add the required interfaces to schedule a VPE and perform a VINVALL command. Reviewed-by:
-
Marc Zyngier authored
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:
-
Marc Zyngier authored
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 set it and find out what breaks. Signed-off-by: -
Marc Zyngier authored
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 authored
After moving a VPE from a redistributor to another, we're still left with a potential pending doorbell interrupt on the old redistributor. That interrupt should be moved to the new one to be either cleared or take, depending on what the hypervisor wishes to do. So let's move it right after having execited VMOVP. This doesn't add much cost in the !DirectLPI case (we trade a DISCARD for a MOVI), and the cost of the DIRECTLPI case should be minimal (two extra MMIO accesses). Signed-off-by: -
Marc Zyngier authored
When we don't have the DirectLPI feature, we must work around the architecture shortcomings to be able to perform the required maintenance (interrupt masking, clearing and injection). For this, we create a fake device whose sole purpose is to provide a way to issue commands as if we were dealing with LPIs coming from that device (while they actually originate from the ITS). This fake device doesn't have LPIs allocated to it, but instead uses the VPE LPIs. Of course, this could be a real bottleneck, and a naive implementation would require 6 commands to issue an invalidation. Instead, let's allocate at least one event per physical CPU (rounded up to the next power of 2), and opportunistically map the VPE doorbell to an event. This doorbell will be mapped until we roll over and need to reallocate this slot. This ensures that most of the time, we only need 2 commands to issue an INV, INT or CLEAR, making the performance a lot better, given that we always issue a CLEAR on entry, and an INV on each side of a trapped WFI. Signed-off-by: -
Marc Zyngier authored
The normal course of action when allocating the ITS' view of a device is to allocate the corresponding LPIs. But we're about to introduce devices that borrow their interrupts from some other entities. So let's make the allocation optional. Signed-off-by: -
Marc Zyngier authored
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:
-
Marc Zyngier authored
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 this method before scheduling the VPE. Reviewed-by:
-
Marc Zyngier authored
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:
-
Marc Zyngier authored
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 hypervisor that there are pending interrupts for this vcpu. Reviewed-by:
-
Marc Zyngier authored
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: -
Marc Zyngier authored
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:
-
Marc Zyngier authored
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 down. All of this is wired into the irq domain alloc/free methods. Signed-off-by: -
Marc Zyngier authored
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:
-
Marc Zyngier authored
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 clearing the Enable bit. Reviewed-by:
-
Marc Zyngier authored
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. The reverse is also done when the VLPI is unmapped from the guest. Signed-off-by: -
Marc Zyngier authored
Add the skeleton irq_set_vcpu_affinity method that will be used to configure VLPIs. Reviewed-by:
-
Marc Zyngier authored
Add the new GICv4 ITS command definitions, most of them, being defined in terms of their physical counterparts. Reviewed-by:
-
Marc Zyngier authored
Add a bunch of GICv4-specific data structures that will get used in subsequent patches. Reviewed-by:
-
- 23 Aug, 2017 8 commits
-
-
Marc Zyngier authored
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 (priority, for example). Reviewed-by:
-
Marc Zyngier authored
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:
-
Marc Zyngier authored
Rework LPI deallocation so that it can be reused by the v4 support code. Reviewed-by:
-
Marc Zyngier authored
Just as for the property table, let's move the pending table allocation to a separate function. Reviewed-by:
-
Marc Zyngier authored
The VCPU tables can be quite sparse as well, and it makes sense to use indirect tables as well if possible. Reviewed-by:
-
Marc Zyngier authored
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:
-
Marc Zyngier authored
Allow the pending state of an LPI to be set or cleared via irq_set_irqchip_state. Reviewed-by:
-
Marc Zyngier authored
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 to guarantee their execution. Given the similarities (post a command, perform a synchronization operation on a sync object), it makes sense to reuse the same mechanism for both class of commands. Let's start with turning its_send_single_command into a huge macro that performs the bulk of the work, and a set of helpers that make this macro usable for the GICv3 ITS commands. Signed-off-by:
-
