On 2/2/19 12:54 PM, Peng Fan wrote:
Hi Julien
Hi Peng,
-----Original Message-----
From: Julien Grall [mailto:julien.gr...@arm.com]
Sent: 2019年2月1日 18:41
To: Peng Fan <peng....@nxp.com>; sstabell...@kernel.org; jgr...@suse.com
Cc: xen-devel@lists.xenproject.org
Subject: Re: [PATCH for-4.12 v2] arm: gic-v3: deactivate SGI/PPI during
initialization
Hi,
We spoke about SPIs in the previous version. Why aren't they de-activated
here?
According to GIC-V3 " 8.9.5 GICD_ICACTIVER<n>, Interrupt Clear-Active Registers, n =
0 - 31"
"
Some or all RW fields of this register have defined reset values.
When this register has an architecturally-defined reset value, this field
resets to 0.
"
I can't find this wording in the last spec (IHI0069E). Can you please
give the version of the specific version of the spec when quoting it?
So I think we no need to deactivated, because it has reset values 0
The specification is about the reset value from the hardware, it does
not tell you how the firmware (or the previous kernel when using kexec)
is going to leave the interrupts. For instance, as I pointed out in a
different thread, Xen may reboot with SPIs activated. This can happen if
you receive the reboot/power off request while handling an SPI.
On 1/30/19 2:00 PM, Peng Fan wrote:
On i.MX8, we implemented partition reboot which means Cortex-A reboot
will not impact M4 cores and System control Unit core. However GICv3
is not reset because we also need to support A72 Cluster reboot
without affecting A53 Cluster.
The gic-v3 controller is configured with EOImode to 1, so during xen
reboot, there is a function call "smp_call_function(halt_this_cpu, NULL, 0);"
, but halt_this_cpu never return, that means other CPUs have no chance
to deactivate the SGI interrupt, because the deactivate_irq operation
is at the end of do_sgi. During the next boot of Xen, CPU0 will issue
GIC_SGI_CALL_FUNCTION to other CPUs. As the Active state for SGI is
left untouched during the reboot, the GIC_SGI_CALL_FUNCTION will still
be active on the non-boot CPUs. This means the interrupt cannot be
triggered again until it get deactivated.
And according to IHI0069D_gic_architecture_specification, chapter
"8.11.3 GICR_ICACTIVER0, Interrupt Clear-Active Register 0", the RW
field of GICR_ICACTIVER0 resets to a value that is architecturally
UNKNOWN.
So set a fixed value during gic-v3 initialization to make sure
interrupts are in deactivated state.
It is a bit unclear what you mean by "fixed value" here. The only thing you do
is clearing active state. So a better wording is "So make sure all interrupts
are
deactivated at during initialization by clearing the state".
How about SPIs?
Replied above. I could add the following to the patch if you think it needed, I
am
not sure whether it is valid that SPI is in active state when Xen booting.
See above, I think this is valid and can happen today.
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 1c1d2604f3..5b9c5559a7 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -622,9 +622,12 @@ static void __init gicv3_dist_init(void)
writel_relaxed(priority, GICD + GICD_IPRIORITYR + (i / 4) * 4);
}
- /* Disable all global interrupts */
+ /* Disable/deactivate all global interrupts */
for ( i = NR_GIC_LOCAL_IRQS; i < nr_lines; i += 32 )
+ {
writel_relaxed(0xffffffff, GICD + GICD_ICENABLER + (i / 32) * 4);
+ writel_relaxed(0xffffffff, GICD + GICD_ICACTIVER + (i / 32) * 4);
+ }
/*
* Configure SPIs as non-secure Group-1. This will only matter
This chunk looks good. I will also write a patch for GICv2 doing the same.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel