On 10/31/19 2:30 PM, Peter Maydell wrote:
HCR_EL2.{VI,VF} aren't set by the CPU, they're set by software (ie the hypervisor running in QEMU). They're for the situation where the hypervisor wants to cause a VIRQ or VFIQ to occur directly (ie not because the hypervisor has programmed the GIC and the GIC is injecting a VIRQ/VFIQ). I have a feeling Linux doesn't use them and always uses the GIC.
This seems to be the case.
What I had in mind for 'a' was the implementation of the bit of the spec that says "When executing at EL2 or Non-secure EL0, any physical interrupt that is configured to be taken at EL2 is subject to the Process state interrupt mask. If the mask bit is set, then the corresponding interrupt will not be taken. If the mask bit is not set, then the corresponding interrupt will be taken." (ie handling of PSTATE.[AIF] when HCR_EL2.{E2H, TGE} == {1, 1}.)
As far as I can see this is all correct.
In particular, the manipulations to HCR_{AMO,FMO,IMO} that are done by arm_hcr_el2_eff based on HCR_{E2H,TGE} means that arm_excp_unmasked and arm_phys_excp_target_el are correct as-is.
The case I'm trying to debug, guest EL1 timer, TGE == 0 && IMO == 1. Which, according to D1-10 routes to EL2, and according to D1-13 is not masked by PSTATE.
I really don't understand how this is supposed to work.
The only thing I can imagine is that the guest EL1 timer is not really supposed to generate a real interrupt, but to silently generate a virq, but I don't see anything in section D11 (Generic Timer in AArch64 State) that validates that hypothesis.
r~