Hi everyone
Even though I still can't explain the phenomenon completely and don't know the purpose of the NXP SPI 229, I found two ways to solve the problem.
First, I have to say that for the original hypervisor implementation I used the GIC EOI mode 0 - i.e. writing the interrupt ID of the pending interrupt to the EOIR register sets the interrupt state directly to inactive. In contrast, the ARM GICv2 architectur specification (@ufedor the GIC-400 maintenance interrupt is officially also mapped to PPI ID 25) recommends for a hypervisor implementation to use GIC EOI mode 1 - i.e. writing the interrupt ID of the pending interrupt to the EOIR only leads to a priority drop of the according interrupt and one has to deactivate it after the VM has handled the virtual interrupt by writing the interrupt ID to the GICC DIR register (c.f. ARM GICv2 architecture specification, chapter 5).
After some tests, I finally found out that by using the GIC EOI mode 1 one can handle the maintenance interrupt on the NXP LS1012a FRDM board as described in the ARM specification documents without any "reasserting problems", in short: (1) Acknowledge the pending interrupt; (2) Inject the virtual interrupt into the VM by (a) setting the accoring virtual IRQ bit in the HCR_EL2 register, (b) enabling the maintenance interrupts in the GIC virtual control register and (c) write the virtual IRQ vector to the GIC LR list register; (3) Drop priority by writing to the GICC EOIR register and hand over execution to the VM; (3) as soon as the VM has handled the interrupt (i.e. written to vEOI) a maintenance interrupt is triggered and execution returns to the hypervisor; (4) Disable the physical interrupt by writing to the GICC DIR register and reset the virtual registers (c.f. step 2).
If someone wants to use the GIC EOI mode 0 (even though ARM doesn't recommend it) for the hypervisor implementation but faces the same "reasserting problem" with the maintenance interrupt as I experienced, I can provide a workaround. As soon as the execution returns to the hypervisor due to the triggered maintenance interrupt, one can (1) completely disable the maintenance interrupt ID 25 (i.e. physically on the distributor); (2) do the steps 3 to 4 as described above; and (3) finally reenable the maintenance interrupt ID 25. As I said, I can neither explain the "reasserting problem" itself nor the workaround for GIC EOI mode 0 - but I am gonna keep an eye on it and will (if I can find some time) test it on other evaluation boards and setups because my development environment uses JTAG debugging over OpenOCD and a customized U-Boot bootloader.
Thanks again, David