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~
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain
