-
Notifications
You must be signed in to change notification settings - Fork 50
SGI support for capDL-tool #77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
03e66a6
0e2f236
78efc72
ff2e6ab
280b0ca
36085a4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -121,6 +121,7 @@ data Cap | |
| | ARMSMCCap { | ||
| capObj :: ObjID, | ||
| capBadge :: Word } | ||
| | ARMSGISignalCap { capObj :: ObjID } | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So this is where the model deviates from reality and the properties are not part of the cap, but instead we pretend here they are elsewhere? I don't understand what the advantage of that is, wouldn't that confuse object creation code when it creates zero sized SGI caps? Those won't be derivates of the UT cap either, so revoking the UT won't automatically clean up the SGI cap, which breaks normally valid assumptions. With this in mind, I really don't like pretending it's an object while it isn't.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree with you, for these caps it'd be conceptually nicer not to do that. Since capDL already deals with the issue for a lot of other cap types, there is infrastructure for fake objects, but no infrastructure for caps with content but without objects (only the control caps have no object in capDL). For the concrete concerns, they are both fine and dealt with by the existing infrastructure for fake objects: the caps are not created from Untypeds and the loader knows that, so their derivation tree is not confused and revocation on UT is not supposed to clean up the object (the sgi_signal objects should not be under any untyped cover in the spec -- maybe I should add an explicit check for that). You can still specify an original cap and a derived cap (there are only two levels for SGISignalCap) and that works fine in the loader as well, it has an explicit SGISignal caps can be revoked either by revoking on the IRQControl cap (which removes all of them, including IRQHandlers), or individually (that's what the second level is useful for) -- that's not specific to capDL, though, that's just how the IRQ-related caps work in the kernel. So it does work fine with the right semantics, and in terms of capDL it does actually fit with how the rest is treated. It is awkward in the formalisation, because for other fake objects there is some kind of state in the kernel I can tie them to, but for these ones there is not, the data is only in the cap. So the indirection is going to be annoying in the proof. But it's better dealing with that only once than trying to build and debug a whole lot of infrastructure for creating caps in a different way to what the rest of the tools are used to. |
||
|
|
||
| -- X86 specific caps | ||
| | IOPortsCap { | ||
|
|
@@ -208,6 +209,9 @@ data KernelObject a | |
| slots :: CapMap a, | ||
| trigger :: Word, | ||
| target :: Word } | ||
| | ARMSGISignal { | ||
| irq :: Word, | ||
| target :: Word } | ||
|
|
||
| -- fake kernel objects for smmu | ||
| | ARMSID | ||
|
|
@@ -256,6 +260,7 @@ data KOType | |
| | ARMSID_T | ||
| | ARMCB_T | ||
| | ARMSMC_T | ||
| | ARMSGISignal_T | ||
| | ASIDPool_T | ||
| | PT_T | ||
| | PD_T | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.