With capmgr, all capabilities are modified only by that one component and all other components use capability manager interface to get resources.
However the current kernel API for INTROSPECT requires the CAPTBL capability of the calling component. INTROSPECT is in most cases used by the schedulers for getting information about TCAPs etc, therefore the current workaround is to copy CAPTBL to only scheduling components.
It could also be used by other non-scheduling components, for example, I've in the past used it for getting the FIRST HPET INFORMATION after programming it, for some alignment issues. I've also used it to flush the HW caches through the HW capability of course from a micro-benchmark program.
@gparmer suggested that we could modify INTROSPECT API to call on the CAPABILITY itself and not on the CT. This means that there will be an additional branch in some of the fast-paths like thread switch etc. In any case, we'd need to discuss further and solve this.
With
capmgr, all capabilities are modified only by that one component and all other components use capability manager interface to get resources.However the current kernel API for INTROSPECT requires the CAPTBL capability of the calling component. INTROSPECT is in most cases used by the schedulers for getting information about TCAPs etc, therefore the current workaround is to copy CAPTBL to only scheduling components. It could also be used by other non-scheduling components, for example, I've in the past used it for getting the FIRST HPET INFORMATION after programming it, for some alignment issues. I've also used it to flush the HW caches through the HW capability of course from a micro-benchmark program.
@gparmer suggested that we could modify INTROSPECT API to call on the CAPABILITY itself and not on the CT. This means that there will be an additional branch in some of the fast-paths like thread switch etc. In any case, we'd need to discuss further and solve this.