Clarification of the behavior of virtual interrupts

[JamesKenneyImperas]

Can you please clarify the behavior of virtual interrupts?

Firstly, I understand that mvien/mvipallow virtual interrupts to be presented to S-mode by M-mode. Suppose that a local interrupt (e.g. ID16) is signalled in this way and also connected externally. Is my understanding correct that if presented as a virtual interrupt it can only be taken to HS/VS mode, whereas when signalled externally it will be taken to M-mode (because mideleg[16] must be 0 in this case)? In other words, is it true that with virtual interrupts the interrupt ID alone is no longer sufficient to determine the target execution level?

Secondly, can you clarify whether virtual interrupts affect the WFI instruction in any way? Do pending virtual interrupts affect whether execution of WFI is allowed to enter a wait state, and is this execution-mode-dependent?

Thanks.

[jhauser-us]

Is my understanding correct that if presented as a virtual interrupt it can only be taken to HS/VS mode, whereas when signalled externally it will be taken to M-mode (because mideleg[16] must be 0 in this case)?

Assuming bit 16 of mideleg is zero, then you are correct.

In other words, is it true that with virtual interrupts the interrupt ID alone is no longer sufficient to determine the target execution level?

True. What you want to pay attention to are the *ip, *ie, and *ideleg registers for each privilege level that can take interrupts. Virtual interrupts show up in sip and vsip, as indicated by the tables in Sections 6.3, "Interrupt filtering and virtual interrupts for supervisor level", and 7.3.2, "Virtual interrupts for VS level".

Secondly, can you clarify whether virtual interrupts affect the WFI instruction in any way?

Yes, because the allowed behavior of WFI is determined by the contents of the *ip and *ie CSRs: mip, mie, sip, sie, hip, hie, vsip, and vsie.

[JamesKenneyImperas]

Thanks, John - closing

[JamesKenneyImperas]

I'm reading further here and realizing there are still details I haven't properly understood about virtual interrupts, especially those delivered by hvictl, and their interaction with WFI. Can you please clarify further? Thanks.

As I understand it, the normal behavior of WFI with basic interrupts (in the absence of AIA) is that it may or may not put the processor into a wait state, but it definitely must not do this if ((mip & mie) != 0). In the normal case, mip and mie encapsulate information about all basic-mode interrupts, so although there are different views of these in the various *ip and *ie registers, it is sufficient to consider just mip and mie for the WFI-mustn't-wait test (obviously, if the interrupt is for a higher privilege level or for this level and enabled in xstatus then it is taken immediately). If some external interrupt is raised while in a wait state such that (mip & mie) is no longer zero, then the processor must restart from wait state, possibly taking the interrupt immediately if it targets a higher-privilege level or is enabled at this level.

Suppose now that AIA is implemented, a virtual interrupt for Supervisor level has been set pending using mvip/mvien, this interrupt is enabled using the writable sie CSR (as described in section 6.3), but the interrupt is not pending in mip. Is it the case that, with the processor in this state:

1. Executing WFI in M-mode may put the processor into a wait state;
2. Executing WFI in S-mode must not put the processor into a wait state?

In other words, whether WFI causes the processor to wait is now mode-dependent and can no longer be determined universally using mip and mie? I think this is the case, but I want to verify my understanding.

Suppose now that AIA and Hypervisor mode are implemented, and the processor is executing in VS mode and there is some pending virtual supervisor interrupt for one of the 5 bulleted reasons described in section 7.3.3, but vsstatus.SIE is zero (so the pending virtual supervisor interrupt is not taken yet). I assume that if a WFI is executed when the interrupt is pended because of bulleted-reasons 1, 2 and 4 then the processor must not be put into a wait state (because ((vsip & vsie) != 0)). But what happens if the interrupt is pended for bulleted reasons 3 or 5? In these cases, ((vsip & vsie) == 0); is it legal to enter a wait state?

I also have a question about state seen in VS-mode for bulleted case 3 (hstatus.VGEIN=0, and hvictl fields IID=9 and IPRIO ̸=0). For bulleted cases 1, 2 and 4, a read of sip will show the virtual interrupt pending in bit 9. For case 5, reading sip is illegal. Is it true that reading sip in case 3 does not show the virtual interrupt as pending?

I'm sorry this is such an essay - thanks in advance for taking the time to consider it.

[JamesKenneyImperas]

It looks like commit #f1d7cf8 makes some of these points obsolete. However I'm still not sure about:

1. Whether my understanding that WFI may behave differently in M-mode and S-mode is correct; and:
2. Whether executing WFI in virtual mode when (hvictl.VTI==1) && (hvictl.IID!=9) can legally enter a wait state - or perhaps this should cause a Virtual Instruction exception, in the same way as sip/sie accesses do in this case?

Thanks.

[jhauser-us]

See if your questions are resolved by commit c31e38e.

[JamesKenneyImperas]

Hello John,

Ok, so you are saying that a pending interrupt indicated in any of mtopi/stopi/vstopi must prevent WFI from putting the hart into a wait state. This is consistent across privilege levels, answering question 1, and answers question 2 as well (the hart must not wait in this case). Thanks.

One note: I think the requirements for exiting wait state could simply be ((mip & mie) != 0) as before, since by definition nothing can have changed virtual interrupt state while the hart is halted (this can only change by executing code, unless I've misunderstood something).

James.