Repository navigation
Conversation
According to the ACPI spec., the SCI pin is driven by multiple inputs that are OR'ed to determine if the guest should receive an interrupt[^1]. Introduce `OrGate`, a new component that can front an `Arc<dyn IntrPin>` as output and and expose multiple inputs. The output pin state is driven by the OR value of the inputs. The new `sci_pin()` method of `Piix3Lpc` creates and returns a new input to the OR gate fronting the SCI pin. [^1]: https://uefi.org/specs/ACPI/6.6/04_ACPI_Hardware_Specification.html#example-event-structure-for-a-legacyacpi-compatible-event-model
When working on more ACPI features, I realized that it would make more sense for an Acpi struct to own the SCI OrGate. The Acpi struct will hold and manage ACPI registers, so it should the one controlling inputs to the SCI gate.
| #[allow(unused)] | ||
| // XXX: wire up SCI notifications | ||
| sci_pin: Arc<LNKPin>, |
There was a problem hiding this comment.
While I was working on the ACPI GPE registers I realized that it would make more sense to move the SCI pin and OrGate to an ACPI-related struct. This struct is going to hold ACPI state, so I think it makes sense that it also controls who connects to the SCI pin.
The struct is not being used in this PR, but here's a preview of how it will look like: c9fd6b7. Other components that an input to the SCI can call acpi.sci_pin().
| /// Internal state is stored in a `<Vec<bool>>` to make the code easier to read | ||
| /// and maintain, but it would be possible to use something like a | ||
| /// [std::sync::atomic::AtomicU64] bitmask instead. |
There was a problem hiding this comment.
I wonder if a Mutex<u64> would be a happy medium here, in terms of not changing much of the logic as-currently-written (it'd largely become just bit shifts instead of array indexing, while still holding locks the same way so we don't trip on ABA problems), but also not requiring dynamic memory allocation and iterating (i.e. .contains(true) becomes != 0)
There was a problem hiding this comment.
Makes sense. I chatted with @iximeow last week about and, since we don't expect that many inputs to the this OrGate, and it doesn't sit in a hotpath, I figured a Vec<bool> would be the most straightforward implementation, but I guess I can hide the bit manipulation logic in a wrapper struct.
How does c331fb6 look like?
2 participants
According to the ACPI spec., the SCI pin is driven by multiple inputs that are OR'ed to determine if the guest should receive an interrupt1.
Introduce
OrGate, a new component that can front anArc<dyn IntrPin>as output and and expose multiple inputs. The output pin state is driven by the OR value of the inputs.The new
sci_pin()method ofPiix3Lpccreates and returns a new input to the OR gate fronting the SCI pin.Footnotes
https://uefi.org/specs/ACPI/6.6/04_ACPI_Hardware_Specification.html#example-event-structure-for-a-legacyacpi-compatible-event-model ↩