v0.1 Comments/Questions: What's the purpose for delegate LDSEI defined in Chapter 6 Smdia

[ram2532]

Chapter 6 "Smdia: Supervisor Domain Interrupt Assigment" ends with this comment regarding the purpose for delegate LDSEI:

The delegation supports optimizing the exit sequence from such supervisor domain by enabling such supervisor domains to voluntarily yield execution in response to pending interrupts for the other supervisor domains.

I don't understand what is being optimized here. A transition to M-mode still needs to happen so that M-mode can switch the context to the interrupted SDID so that the interrupt can be handled. I don't understand the purpose for this delegation.

I also think this chapter would benefit from a S/W view of how S/W would use the Smsdia functionality to manage external supervisor interrupts across multiple SDIDs. I infer from the description of the CSRs, that M-mode would need to clear the msdeie bit corresponding to the SDID of the Supervisor context to which it will MRET. I think a description of how M-mode handles these transitions would be helpful.

[gagachang]

Hi @ram2532 ,

I don't understand what is being optimized here. A transition to M-mode still needs to happen so that M-mode can switch the context to the interrupted SDID so that the interrupt can be handled. I don't understand the purpose for this delegation.

Consider that SD(1) is running, and suddenly an SD(2)'s interrupt is asserted.
The general program flow is:

1. M-mode receives LSDEI which is from SD(2)'s interrupt controller
2. M-mode should notify SD(1) and MRET to SD(1), to let SD(1) suspend itself
3. SD(1) suspends itself, then executes ecall to go back to M-mode
4. M-mode switches context to SD(2) to let SD(2) handle this interrupt

The delegation of LSDEI can eliminate the step 1 and step 2.
Because the delegation makes SD(1) receive LSDEI directly.
The M-mode's notification is unnecessary.

[rsahita]

@ram2532 any more questions on this one? - this usage scenario was previously discussed in Issue #34

[ram2532]

@rsahita - I had not seen issue #34. I'm far from an expert in TEEs so I don't know all use cases or requirements. From what I see, this feature does require the RSDM to have a whole lot of trust in the SD to which it delegates these interrupts. This is a delegation of pending S/VS interrupts from all other active SDs to a single SD. That one SD controls how quickly the S/VS interrupts of all other SDs can be taken.

Are we saying that in this use case, this level of trust is there? Or, is it more desirable to partition these interrupts so that some are be delegated to an SD and the rest at taken to M-mode?

Like I mention, I'm not an expert. I'm asking to make sure what is specified is something that S/W can and will use.

[rsahita]

@ram2532 So far the use case feedback we got that it is sufficient for one case for RDSM to delegate all interrupts to a trusted SD to manage it for one another untrusted SD; or alternately all interrupts be managed by M-mode RDSM (for all SDs) - other exotic cases can be considered in the future the use cases arise (none that I am aware of today).

[ram2532]

@rsahita Thanks for your responses. No more questions.