Page MenuHomeFreeBSD

gicv3_its: do LPI init only once per CPU

Authored by jchandra on Apr 8 2019, 2:19 AM.



The initialization required for LPIs (setting up pending tables etc.) has to be done just once per CPU, even in the case where there are multiple ITS blocks associated with the CPU.

Add a variable lpi_enabled in the per-cpu distributor info for this and use it ensure that we call its_init_cpu_lpi() just once.

This enables us to support the case where multiple ITS blocks can generate LPIs to a CPU.

Diff Detail

rS FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

jchandra created this revision.Apr 8 2019, 2:19 AM
andrew added inline comments.Apr 13 2019, 10:26 AM
46 ↗(On Diff #55932)

Just make this an int or bool. The struct will be padded any way so it doesn't save any space.

674 ↗(On Diff #55932)

How do we get into its_init_cpu on a given CPU? I assume it's when there are multiple ITS devices.

Let me know if you need a new rev with bool.

46 ↗(On Diff #55932)

The idea was to use other bits for more flags if needed. I think bool would work as well, if the bit field is looks like an unnecessary complication.

674 ↗(On Diff #55932)

gicv3_its_init_secondary calls it for each secondary CPU.

This is to handle the case when there are multiple ITS blocks associated with a CPU. We need to do the LPI init once per CPU (per- redistributor actually). The collection init has to be done for all the ITS blocks.

So the idea is to get a per-redistributor flag to mark LPI initialization status.

If you think more flags will be needed later you can make it a u_int with a per-flag macro. If not just make it a bool.

46 ↗(On Diff #55932)

You could also make it a u_int and define a flag. e.g.:

struct redist_pcpu {
  u_int flags;

674 ↗(On Diff #55932)

Ok, it would pay to explain this in a comment.

jchandra updated this revision to Diff 57925.May 26 2019, 11:28 PM
jchandra edited the summary of this revision. (Show Details)
andrew accepted this revision.May 27 2019, 10:36 AM
This revision is now accepted and ready to land.May 27 2019, 10:36 AM
This revision was automatically updated to reflect the committed changes.