Re: [Qemu-devel] State of ARM FIQ in Qemu

[Greg Bellows]

On 13 November 2014 10:46, Peter Maydell <address@hidden> wrote:

On 13 November 2014 16:26, Tim Sander <address@hidden> wrote:
> This is the gcc inline assembly syntax from my kernel module written in c:
> asm("mrc p15, 0, %0, c12, c0, 0" : "=r"(vbar) : : "cc");
> asm("mrc p15, 0, %0, c12, c0, 1" : "=r"(mvbar) : : "cc"); <- not implemented?
> asm("mrc p15, 4, %0, c12, c0, 0" : "=r"(hvbar) : : "cc");  <- not implemented?
>
> It seems as if neither mvbar nor hvbar are implemented and that vbar returns
> zero !? I also have a problem with the addresses:
> The fiq handler lies at 0xffff1240 but the vectors_page in Linux points to
> 0xbfffe000? You where talking about the fact that the security extensions
> where not implemented. I was not aware that the different vbar's where
> already part of the security stuff?

MVBAR is part of the Security extensions. HVBAR is part of the
Virtualization extensions. In mainline QEMU we implement neither
of those extensions, and so don't implement the associated
registers. (Strictly speaking, VBAR is also only in the
Security extensions, but we provide it as a workaround for
guests that assume our CPUs should implement it.)

Peter beat me to it.  None of the VBAR registers should matter in your case which coincides with the use of hivecs.  

It may be worthwhile to put a kernel breakpoint in handle_fiq_as_nmi() just to see where it goes.  If CONFIG_ARM_GIC is enabled it should take you to your handler I suspect.  Plus, if you get there then we have likely proven that QEMU is getting the kernel to the right place.  I set a BP in this routine on my A9 run and appear to be hitting it correctly.

Let me know how I can help in debugging the QEMU side of things.

 

-- PMM