Hi,
Somehow, I didn't receive the e-mail on my Arm account.
On 26/04/18 15:23, Tim Deegan wrote:
At 11:08 +0100 on 26 Apr (1524740921), Julien Grall wrote:
On 20/04/18 13:25, Mirela Simonovic wrote:
This looks a bit weird. AFAIU, if you disable the CPU interface, then you
should never receive interrupt after. So why would you re-enable them?
I realize the code in __cpu_disbale do that, but this looks quite wrong to
me. There are no way to receive queued timer interrupt afterwards.
That is what I took as a reference, but I asked myself the same.
There is (extremely small, but it exists) time window between
disabling irq locally and disabling CPU interface. An interrupt
received in that time window would propagate to the CPU but I'm not
sure would happen after the GIC CPU interface is disabled and
interrupts are locally enabled. That is the only explanation I can
come up with, although I believe the answer is nothing. Since you're
at ARM you could check this internally.
Speaking with Andre (in CC), the GIC CPU interface may have forwarded an
interrupt to the processor before it gets disabled. So when the
interrupt will be re-enabled, the processor will jump to the interrupt
exception entry.
However, looking at the spec (4-78 in ARM IHI 0048B.b), Xen will read a
spurious interrupt ID from GICC_IAR. So I am not sure what the point of
that code. It looks like it has been taken from x86, but some bits are
missing.
AFAIU, x86 will only suspend the timer afterwards (see time_suspend). I
am not fully sure why this code is there on Arm. Whether we expect a
timer interrupt to come up. Stefano, Tim, do you have any insight on
that code?
Sorry, no. I pretty clearly copied this logic from x86, which copied
it directly from Linux at some point in the past. I don't know why
x86 does it this way, and I haven't dived into linux to find out. :)
But draining the outstanding IRQs seems like a polite thing to do if
you're ever going to re-enable this CPU (at least without resetting
it first).
I am not entirely sure what you mean by draining, do you mean they will
serviced by Xen? If so, what kind of interrupts do you expect to be
serviced (e.g PPI, SPIs) ?
AFAIU, you will not be able to read outstanding interrupts as the
GICC_IAR will always return a spurious interrupt when the GIC CPU
interface is disabled. So you will still take the exception if the
interface signaled the processor for an incoming interrupt but all the
interrupts will stay pending.
Clearly, this code does not seem to be doing what we are expecting.
Speaking the Marc Z. (GIC maintainers in Linux), there are no need to
disable the GIC CPU interface in the hypervisor/OS. You are going to
shutdown the CPU and it will be reset when you are coming back.
So I think we should drop the gic_disable_cpu() call. I am not sure yet
what/if we should with something here. I will wait your answer on my
question above.
Mirela, looking at the PSCI spec, it seems you have to migrate away all
the interrupts from the core before powering down (see 5.5.2 in ARM DEN
0022D). So I think you need to ensure that even SPIs are moved away.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
