On Thu, 31 Oct 2019 at 13:15, Richard Henderson richard.henderson@linaro.org wrote:
As soon as the guest kernel enables interrupts,
arch_timer_starting_cpu enable_percpu_irq irq_percpu_enable gic_unmask_irq -- Incorrect exception delivery.
the GTIMER_PHYS interrupt is delivered to EL2 (seems to be ok), the host kernel does something (haven't dug into what exactly, bug presumably setting bits that are supposed to pass the virq to the guest), and immediately another interrupt is delivered to EL2. Repeat.
Whether this is incorrect routing of the virq interrupt, or incorrect masking/acking of the hard irq interrupt at EL2, I do not yet know.
PMM: I don't know the answer to either (a) or (b) as asked on hangouts. I think (b) is correct, but I can't be sure. I'm trying to understand how (a) is supposed to work now. In particular, I can't find any code that sets HCR_EL2.{VI,VF}, only tests them.
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.
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}.)
thanks -- PMM