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
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 56178 Build 53066: arc lint + arc unit
Event Timeline
| sys/arm64/arm64/gicv3_its.c | ||
|---|---|---|
| 701 | Could we get into a situation where the first ITS device isn't enabled, but any others are? | |
| sys/arm64/arm64/gicv3_its.c | ||
|---|---|---|
| 701 | 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. | |