lazy Scheduling Context rebind + improve tool <-> monitor ABI#439
lazy Scheduling Context rebind + improve tool <-> monitor ABI#439dreamliner787-9 wants to merge 2 commits intoseL4:mainfrom
Conversation
d10d766 to
417fbb1
Compare
417fbb1 to
d500f22
Compare
There was a problem hiding this comment.
First, this really should be two separate commits, not lumped together like this.
Secondly, I'm missing creating a notifications object for passive servers that don't otherwise have one already, and binding the SC to the notification object if the PD is passive.
That last thing is really the only change you need compared to active PDs for setup.
Only other change needed is that you bind the SC when restarting the task, but I don't think Microkit does that yet, but rust-sel4 does I think.
monitor/src/main.c
Outdated
| /* If there are passive PDs in the system, lazily rebind it's Scheduling Context and resume TCB. | ||
| * To workaround https://github.com/seL4/seL4/issues/1617 by applying https://github.com/seL4/seL4/pull/523 | ||
| */ | ||
| for (unsigned idx = 0; idx < pd_metadata_len; idx++) { | ||
| if (pd_metadata[idx].passive) { | ||
| seL4_Error err = seL4_SchedContext_Bind(BASE_SCHED_CONTEXT_CAP + idx, BASE_NOTIFICATION_CAP + idx); | ||
| if (err != seL4_NoError) { | ||
| puts("MON|ERROR: could not bind scheduling context to notification object\n"); | ||
| continue; | ||
| } | ||
|
|
||
| err = seL4_TCB_Resume(BASE_PD_TCB_CAP + idx); | ||
| if (err != seL4_NoError) { | ||
| puts("MON|ERROR: could not bind resume passive PD TCB\n"); | ||
| continue; | ||
| } | ||
|
|
||
| puts("MON|INFO: PD '"); | ||
| puts(pd_metadata[idx].name); | ||
| puts("' is now passive!\n"); | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
There is no need to do this resume and you can bind the SC to the notification when you create the notification for a passive thread. This feels like the wrong place for that.
There was a problem hiding this comment.
There is no need to do this resume
I think this ties in to my reply below.
and you can bind the SC to the notification when you create the notification for a passive thread. This feels like the wrong place for that.
We did consider binding the PD's Notification to the SC in the initialiser by adding a passive: bool to the TCB spec object. But we felt like the initialiser should not be concerned with this detail.
| // Passive PDs are resumed by the Monitor | ||
| pd_tcb.extra.resume = !pd.passive; |
There was a problem hiding this comment.
Hi Indan, we intended for passive PDs to be resumed by the monitor, because we don't want them to start processing events before being converted to passive. Which can happen on multi-core.
Improved tool <-> monitor ABI by creating a metadata struct per PD, rather than adding a new symbol for every type of metadata. Signed-off-by: Bill Nguyen <bill.nguyen@unsw.edu.au>
Yes I agree, will split them up.
All PDs have a notification object in their capDL spec so they will be created automatically by the initialiser. microkit/tool/microkit/src/capdl/builder.rs Lines 710 to 736 in da0ca91
Yes, the capDL initialiser configure SCs and bind them to TCBs for us, so we only need to bind Notification to SC for passive PDs. |
Signed-off-by: Bill Nguyen <bill.nguyen@unsw.edu.au>
d500f22 to
bfc5e01
Compare
Applied seL4/seL4#523 to workaround seL4/seL4#1617, and improved tool <-> monitor ABI by creating a metadata struct per PD, rather than adding a new symbol for every type of metadata.