qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gicv3 maintenance interrupt not triggering


From: Philippe Mathieu-Daudé
Subject: Re: gicv3 maintenance interrupt not triggering
Date: Wed, 23 Sep 2020 10:06:44 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

Hi Jose,

On 9/22/20 10:46 PM, Jose Martins wrote:
> Hey Peter, thank you for the prompt response.
> 
> In reverse order:
> 
>> (You don't say what QEMU version you're using or what command line
>> you use to start QEMU -- those are both always useful information
>> for "I'm trying to do something with QEMU and it's not working"
>> queries...)
> 
> I've compiled QEMU 5.1.0 which I configured using: ./configure
> --target-list=aarch64-softmmu

You can enable a trivial tracing backend (displaying trace events
to stderr) as suggested by Peter in (a) by adding
'--enable-trace-backends=log' to your ./configure.

> This is how invoke QEMU: qemu-system-aarch64 -nographic -M
> virt,secure=on,virtualization=on,gic-version=3 -cpu cortex-a53 -smp 4
> -m 4G -bios systemimage.bin

Then you can select all the GICv3 events adding '-trace gicv3\*'.

You can combine filter, i.e.:'-trace gic\* -trace -gicv3_redist\*'
to select generic GIC and GICv3, except the redistributor events.

> 
>> Given the MISR and HCR values you quote I would also check that
>> you've set up the maintenance interrupt itself correctly, ie that
>> it isn't disabled or similar such that the GIC asserts it but
>> nothing happens.
> 
> If that was the case, the pending bit in the gicr.ispendr0 would still
> be set, but it would just not raise the irq line to the cpu.
> Nevertheless, I know the interrupt is correctly setup because if I set
> it pending by writing to gicr.ispendr0, the interrupt is triggered and
> the final handler executes.
> 
>> You might like to (a) enable some or all the QEMU gicv3 trace events to
>> see if they provide any insight into what the emulated GIC is doing when
>> your guest prods it, and/or (b) run QEMU under a debugger and look at what
>> it is doing in gicv3_cpuif_virt_update() (and in particular when it
>> calls maintenance_interrupt_state()) to see what it thinks it
>> is setting the maintenance interrupt line to.
> 
> I'll try to dig deeper tomorrow. But just now doing some basic printf
> debugging, I've noticed that cs->maintenance_irq is NULL which results
> in the call to qemu_set_irq returning without calling the
> irq->handler.
> 
> Thanks,
> Jose
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]