Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • F firmware
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Graph
    • Compare
  • Issues 74
    • Issues 74
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 29
    • Merge requests 29
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • External wiki
    • External wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • card10card10
  • firmware
  • Merge requests
  • !474

Disable core 1 interrupts during API calls

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Rahix requested to merge rahix/no-irq-epic-calls into master Jul 04, 2021
  • Overview 2
  • Commits 3
  • Pipelines 1
  • Changes 4

@schneider, this is for you :) I think I've managed to figure out how to solve the lockup you observed in a way that's both compatible with the old (non-masking API calls) and new (irq-masking API calls) schemes. Please take a close look though, I'm a bit scared that I might have again missed something here...

Commit 7fb48178 ("feat(lifecycle): Allow core 1 to disable interrupts during API calls") is the important part. The commit message explains the details:

When interrupts are disabled during API calls on core 1, we can only trigger a core 1 reset when there is no API call ongoing. This means that the lifecycle machinery needs to allow any running API calls to complete before it has a chance to see its reset interrupt delivered.

This is complicated because we cannot synchronize on core 1 triggering an API call - the best we can do is stop the dispatcher, check whether our reset interrupt was delivered, and if not, give it another chance to process an API call.

Additionally, "give it another chance to process an API call" means that the IDLE task must run, because this is currently a prerequisite to scheduling the dispatcher (see API call mechanism). The only way to facilitate this is with a sleep that is long enough that it will eventually let core 0 go idle. It seems that an 8 tick delay does the job quite fine.

Thus, implement a busy loop which provides the above requirements and with that makes Epicardium prepared for payloads which perform API calls with interrupts disabled.

Ontop, I then added the critical section in the API caller code in commit 92741109 ("feat(api-caller): Hard-disable all IRQs during API calls"). Note that I am currently disabling absolutely everything here - we might want to revise this in the future to allow some kind of "NMI execution stage" which can still run but then cannot call API calls. Doing this would break the sleep-usecase again, though...

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: rahix/no-irq-epic-calls