The function its_init_cpu_lpi() will configure the LPIs for a given CPU. One part is to configure the GICR_PROPBASER which contains, among other fields, the size of the property table. This is computed as followed:

```
        size = (flsl(LPI_CONFTAB_SIZE | GIC_FIRST_LPI) - 1);

        xbaser = vtophys(sc->sc_conf_base) |
            (GICR_PROPBASER_SHARE_IS << GICR_PROPBASER_SHARE_SHIFT) |
            (GICR_PROPBASER_CACHE_NIWAWB << GICR_PROPBASER_CACHE_SHIFT) |
            size;
```

Per the GIC specification (12.11.31 in ARM IHI 069G), the ID bits is:

```
The number of bits of LPI INTID supported, minus one, by the LPI Configuration table starting at Physical_Address.
```

As the function flsl returns the last bit set starting from 1 (e.g. if the value 1 is passed, then the return is 1), I think the size should be computed using
flsl(...) - 2.

The size is also used by the pending table which can't be touched by the OS once the LPIs has been enabled:

```
During normal operation, the LPI Pending table is maintained solely by the Redistributor.
Behavior is UNPREDICTABLE if software writes to the LPI Pending tables while GICR_CTLR.EnableLPIs == 1.
When GICR_CTLR.EnableLPIs is cleared to 0, behavior is UNPREDICTABLE if the LPI Pending table is written
before GICR_CTLR.RWP reads 0.
```

As we don't know the content past the region, this could lead to strange behavior. Although, I am not aware of any issue right now.

This will also become a problem in confidential compute, because FreeBSD may end up to declassify more memory than we should.

I am not posting a formal patch because I don't have a setup to build FreeBSD yet.