vm_arm: add priority in vm config struct #69
Conversation
axel-h
force-pushed
the
patch-axel-19
branch
2 times, most recently
from
78628ad
to
f8e29e7
Compare
Since we had forked off our completely independent versions of VM definition and configuration macros, we could not track upstream changes. Configuration macro still needs the change, but is pending on seL4/camkes-vm#69. Signed-off-by: Hannu Lyytinen <[email protected]>
Since we had forked off our completely independent versions of VM definition and configuration macros, we could not track upstream changes. Configuration macro still needs the change, but is pending on seL4/camkes-vm#69. Signed-off-by: Hannu Lyytinen <[email protected]>
axel-h
force-pushed
the
patch-axel-19
branch
9 times, most recently
from
71672c1
to
071662a
Compare
|
Also, shouldn't you get rid of hard coded value at (and the other one on line 35 also)? |
Yes, seems this can also be removed then. |
axel-h
force-pushed
the
patch-axel-19
branch
4 times, most recently
from
67883a6
to
dd8c84a
Compare
| @@ -30,9 +30,6 @@ assembly { | |||
| vm.cnode_size_bits = 23; | |||
| vm.simple_untyped24_pool = 12; | |||
|
|
|||
| vm.base_prio = 100; | |||
|
|
|||
| vm._priority = 101; | |||
There was a problem hiding this comment.
_priority has a special meaning as the priority for the thread that calls run
There was a problem hiding this comment.
Thanks, worth to add this in a comment. But shouldn't this be 100 then?
There was a problem hiding this comment.
If the VMM threads aren't a higher priority than the vm thread, the vm won't be preempted when there's work to be done in the VMM which affects things like IRQ latency.
There was a problem hiding this comment.
But the "VM Thread" is the vCPU thread, right? This is supposed to run at "basePrio - 1".
There was a problem hiding this comment.
Check for vcpu_prio < base_prio && vcpu_prio < irqserver_prio is missing in that Jinja template. Probably that's what @kent-mcleod meant?
There was a problem hiding this comment.
I guess it could still be up to someone to choose to configure the vmm and vcpu threads with the same priority if they wanted to delay things like IRQ injection until the vcpu thread was preempted or yielded, but in general, it's probably most straight forward if the irq server threads have equal or higher prio to vmm thread, which has higher prio to vcpu threads.
axel-h
force-pushed
the
patch-axel-19
branch
2 times, most recently
from
8ec23e8
to
6992b29
Compare
axel-h
force-pushed
the
patch-axel-19
branch
4 times, most recently
from
381b9fb
to
630b177
Compare
axel-h
force-pushed
the
patch-axel-19
branch
2 times, most recently
from
d4dc1cd
to
585c92a
Compare
axel-h
force-pushed
the
patch-axel-19
branch
3 times, most recently
from
76ec47e
to
eb4f050
Compare
axel-h
force-pushed
the
patch-axel-19
branch
2 times, most recently
from
fe7a275
to
2723e28
Compare
axel-h
force-pushed
the
patch-axel-19
branch
from
2723e28
to
e787687
Compare
axel-h
force-pushed
the
patch-axel-19
branch
6 times, most recently
from
9133e53
to
8cd023c
Compare
- Cleanup the definitions. - Set a default base value for the attribute. - Derive the other priorities in the config params template. - Do sanity check during template processing. Signed-off-by: Axel Heider <[email protected]>
Adds the priorities to the vm config struct from the template. Is also makes
VM_INIT_DEFuse 100 as default base priority, so there is no need to explicitly specify anything. It also support the_priority. However, I wonder if we should clean this up an rename it to ìrqserver_prio`in the attribute also in a follow-up task