[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH for-4.12 v2] arm: gic-v3: deactivate SGI/PPI during initialization





On 2/2/19 12:54 PM, Peng Fan wrote:
Hi Julien

Hi Peng,

-----Original Message-----
From: Julien Grall [mailto:julien.grall@xxxxxxx]
Sent: 2019年2月1日 18:41
To: Peng Fan <peng.fan@xxxxxxx>; sstabellini@xxxxxxxxxx; jgross@xxxxxxxx
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.