gicv3: Panic if the gicv3 already running

[imp]

Summary

Due to undefined behavior, it's impossible to re-program a gicv3 ITS
table once it's programmed once. Memory corruption happens otherwise.
Panic if we detect the LPI is already enabled.

Sponsored by: Netflix

[andrew]

sys/arm64/arm64/gicv3_its.c

698

Could we get into a situation where the first ITS device isn't enabled, but any others are?

[imp]

sys/arm64/arm64/gicv3_its.c

698

I don't think so. We already have a singleton PROPBASER for the whole system before these changes. The children of that singleton (the ITS) should be ordered from 0 up. I cannot think of a way that it would be otherwise, but if there is some way for that not to be the case, then we'd have to do something more defensive. At worst, though, we can know that there will only be one at a time running due to subr_bus only doing the children one at a time. Looking at the probe/attach routines and knowing that fdt and acpi don't have unit numbers, I think we're OK... If you're worried, or have seem something contrary to what I just said, then we can drop back to doing this if conf_table isn't set and relying on subr_bus to only call one of these at a time.

[imp]

update per review