- 31 Aug, 2017 36 commits
-
-
Minghuan Lian authored
For LS1046a and LS1043a v1.1, the MSI controller has 4 MSIRs and 4 GIC SPI interrupts which can be associated with different Core. So we can support affinity to improve the performance. The MSI message data is a byte for Layerscape MSI. 7 6 5 4 3 2 1 0 | - | IBS | SRS | SRS bit0-1 is to select a MSIR which is associated with a CPU. IBS bit2-6 of ls1046, bit2-4 of ls1043a v1.1 is to select bit of the MSIR. With affinity, only bits of MSIR0(srs=0 cpu0) are available. All other bits of the MSIR1-3(cpu1-3) are reserved. The MSI hwirq always equals bit index of the MSIR0. When changing affinity, MSI message data will be appended corresponding SRS then MSI will be moved to the corresponding core. But in affinity mode, there is only 8 MSI interrupts for a controller of LS1043a v1.1. It cannot meet the requirement of the some PCIe devices such as 4 ports Ethernet card. In contrast, without affinity, all MSIRs can be used for core 0, the MSI interrupts can up to 32. So the parameter is added to control affinity mode. "lsmsi=no-affinity" will disable affinity and increase MSI interrupt number. 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
A MSI controller of LS1043a v1.0 only includes one MSIR and is assigned one GIC interrupt. In order to support affinity, LS1043a v1.1 MSI is assigned 4 MSIRs and 4 GIC interrupts. But the MSIR has the different offset and only supports 8 MSIs. The bits between variable bit_start and bit_end in structure ls_scfg_msir are used to show 8 MSI interrupts. msir_irqs and msir_base are added to describe the difference of MSI between LS1043a v1.1 and other SoCs. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Minghuan Lian authored
LS1046a includes 4 MSIRs, each MSIR is assigned a dedicate GIC SPI interrupt and provides 32 MSI interrupts. Compared to previous MSI, LS1046a's IBS(interrupt bit select) shift is changed to 2 and total MSI interrupt number is changed to 128. The patch adds structure 'ls_scfg_msir' to describe MSIR setting and 'ibs_shift' to store the different value between the SoCs. Signed-off-by:
-
Minghuan Lian authored
LS1046a includes 3 MSI controllers. Each controller supports 128 interrupts. Acked-by:
-
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
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:
-
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 4 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:
-
